Let an in-flight upload finish instead of dying on a rollout

Fixkamo-internal
Ya
8 Agosti 2026, 03:40 UTC
Mwandishi
kamo
Ahadi ya
913da0a

A 2 GiB chat attachment reached 100% and then failed with 'Bad Gateway' because a deploy landed on top of it: the pod took SIGTERM at 03:34:36 and the transfer, seven minutes in, was severed five seconds later. Two causes. Next handles SIGTERM with a bare process.exit(143), so in-flight requests die immediately no matter what grace period is set; and the grace period was 5s anyway. Both were harmless when requests lasted milliseconds. Now a single attachment can occupy a connection for minutes while this cluster deploys on every push, so any concurrent push destroys an upload. SIGTERM now drains: stop accepting new connections, drop idle keep-alives at once so the pod leaves rotation immediately, and let running requests finish. Next's handler is intercepted rather than merely outranked, because an exit() inside any listener wins outright. A pod with nothing in flight still exits in about a second, so ordinary rollouts are unchanged; only a pod with real work to finish waits, capped at 600s under a 660s grace period and a 900s progress deadline that matches the timeout the deploy workflow already waits with.

Mabadiliko yote

Je, unaona nini kuhusu usafiri?

Kila moja ya hizi updates ardhi katika nafasi yako ya kazi moja kwa moja. Kuanza bure na kuangalia kukua wiki baada ya wiki.

Kuwa Huru MileleMtazamo wa bei