Cloud Run Request Termination Signal After Client Cancellation
0 reputation · 28 Oct 2024, 13:11 UTC
Cloud Run Request Termination Signal After Client Cancellation
Goal: determine whether Cloud Run exposes a distinguishable termination signal when an HTTP client cancels a request before the configured request timeout expires, versus when the platform itself enforces the timeout (2nd generation default five minutes, maximum sixty minutes).
Constraint: a client TCP disconnect does not immediately stop the container handler. Execution continues until the request timeout unless the application checks runtime-specific disconnect signals, and Cloud Run logs may not separate client cancellation from platform timeout.
Uncertainty: it is unclear whether application logs can reliably attribute the termination cause, or whether background work started after response headers are sent receives any guaranteed grace before SIGTERM and SIGKILL.
Does Cloud Run log client-initiated cancellation separately from server-enforced timeout? Can application context cancellation detect client disconnect before the platform sends SIGTERM? Is there a supported grace period for cleanup after response headers are sent?