Cancellation and structured concurrency

A useful task state machine separates running, cancellation requested, cleaning up, and terminal. A request can race with normal success, and the terminal outcome may therefore still be success. Decide how the application resolves that race and record one authoritative outcome. Avoid treating a Boolean cancellation flag as proof that a socket or memory region is unused. An operating system request may continue after the coroutine that initiated it no longer wants its answer; a remote service can also commit a side effect before it sees your disconnect.

In Python asyncio, cancellation injects CancelledError at a cooperative opportunity. Cleanup belongs in a finally block; when cancellation is caught explicitly, it generally needs propagation after cleanup. These semantics explain why a CPU loop that never yields can delay cancellation. They do not promise to stop arbitrary blocking work or reverse an external transaction. When wrapping another execution mechanism, document its separate stop and join protocol instead of assuming cancellation crosses every boundary.

A structured task group owns the children it starts and waits for them before its scope exits. Python TaskGroup also cancels remaining children when a child fails with an ordinary non-cancellation exception, then collects failures after waiting. This gives callers a place to observe errors and reason about the completion of owned work. An intentionally detached background service needs a different explicit owner, shutdown path, and failure observer; simply dropping its handle creates none of those guarantees.

Treat cleanup ordering as a dependency problem. Stop admitting new work before draining children; keep shared resources alive until the last dependent child is terminal; close those resources afterward. Independent child cleanups can overlap, so their durations need not add. However, closing a shared connection before a child finishes using it can create a second failure that obscures the first. Shielding selected cleanup from cancellation can be appropriate, but the shielded activity still needs a retained handle and someone responsible for joining it.

A request deadline and a resource-release deadline are different measurements. A user-facing timeout can expire while cleanup continues, so reserve time and capacity for that tail. Make repeated shutdown requests idempotent: the second request should not double-close a resource or discard the only completion observer. Exercise deterministic schedules in tests: completion before cancel, cancel before completion, failure during cleanup, and simultaneous sibling failures. Assert both the reported outcome and that all owned work and resource references have been accounted for.

Use the queue lab as a narrow drain analogy. Its arrival-rate and service-rate controls move a fluid backlog initially equal to four. Press Reset, set arrival rate to zero and service rate to four units per second, predict the drain time, then press Play and pause at the empty point. For a separate comparison, press Reset again, explicitly set both arrival and service rates to four, predict whether the new run drains, then press Play. This illustrates why shutdown first closes admission; it is not an execution trace of TaskGroup, does not model cancellation delivery, and cannot prove that your actual children released their sockets.