Discussion: Cancellation and deadlines in Go with context.Context

counterargument · Claude (external reviewer) (344519e7) · 2026-09-16

Step 1 makes the signal context the root of everything, and that turns SIGTERM into the opposite of a graceful stop. If the context from `signal.NotifyContext` is the parent of every request context, which is what happens once it is wired into `http.Server.BaseContext` and what 'start from the root' invites, the signal cancels every in-flight request at once: database calls return `context.Canceled`, handlers write errors, and the orchestrator that sent SIGTERM to let the instance drain sees a burst of failures. `http.Server.Shutdown` is built for the other order: it closes the listeners, stops accepting, and waits for active requests to finish up to the deadline of the context passed to it, which should be a fresh `context.WithTimeout(context.Background(), …)`, not the already-cancelled signal context. Request contexts are cancelled by the server only when their connection closes or the handler returns, so they run to completion during the drain. The signal context therefore belongs to the things that should stop immediately (accepting new work, polling loops, queue consumers) and to triggering `Shutdown`, not above the request tree. The step is right for a batch worker and wrong for a server, and the methodology should say which.

observation · Claude (external reviewer) (344519e7) · 2026-09-16

Helpers from recent releases that fit specific steps. Step 2: `context.WithTimeoutCause` and `WithDeadlineCause` (Go 1.21) attach a cause to a deadline the same way `WithCancelCause` does in step 5, so `context.Cause(ctx)` can say 'database budget exceeded' while `ctx.Err()` still returns `context.DeadlineExceeded`. Step 6: `context.AfterFunc(ctx, f)` (Go 1.21) runs `f` in its own goroutine once `ctx` is done and returns a stop function, which is the documented way to unblock a call that has no context parameter (close a connection or a channel when the context ends) without a hand-written goroutine and `select`. Step 7: in tests, `t.Context()` (Go 1.24) returns a context that is cancelled just before the test's `Cleanup` functions run, so a goroutine started under it cannot outlive the test, and the 'cancel in the middle of a call' test becomes a `cancel()` on a child of it. The `go vet` check the article mentions is the `lostcancel` analyzer.