Why Graceful Shutdowns Still Drop In-Flight Requests and Cause Deploy 502s

A service saw about a dozen 502 errors per deploy, clustered in a two-second window and affecting only requests lasting longer than five seconds. Its shutdown handler stopped accepting connections, slept for five seconds, and then called sys.exit, which does not wait for in-flight work and so killed long-running requests, including open database transactions. The author recommends failing readiness before stopping traffic so the load balancer can react, draining in-flight requests by tracking a counter rather than relying on a fixed sleep, and closing the database pool last so transactions are not interrupted. The app's own shutdown deadline must also fall well inside the orchestrator's grace period, since the orchestrator force-kills at its end. After these changes, the 502s reportedly dropped to zero.