Structured Concurrency

With no owner waiting, the error has nowhere to propagate: it ends that task and lands in a default handler, an unread log line, or a result object nobody inspects. The system keeps reporting healthy while the work silently is not being done.

Nobody owns it. Failures vanish silently, nobody waits for it, it can outlive the data and resources it borrowed, it cannot be cancelled or given a deadline, and shutdown can kill it mid-work. The leak stays invisible.

A checkpoint is a point where the task tests the cancellation signal and abandons the work if it is set. Blocking and awaiting operations usually provide them implicitly; a pure compute loop has none, so you poll the signal every N iterations. Cancellation latency is roughly the time between checkpoints plus cleanup time.

Forced termination stops a task at an arbitrary instruction, so invariants are half-updated, locks and buffers are left in unknown states, and no cleanup runs. Cooperative cancellation stops only at safe points. A thread interruption flag is the same idea at thread level: a bit that blocking operations honour by aborting early.

By default the scope fails fast: the first failure determines the overall result, so the siblings are cancelled immediately, the scope waits for them to finish unwinding, and the failure is reported to the caller after about 50 ms instead of 10 seconds.

It makes concurrency nest like a block of code: on exit no task from that block is still running. So lifetimes are bounded, errors have somewhere to propagate, and cancellation has a subtree. Cost: the slowest child gates the block, so you must add timeouts and cancellation.

Usually nothing has stopped. A timeout only means the caller stopped waiting; it must then cancel the work region, wait for it to unwind, and release its resources. And a timed-out write is ambiguous — it may still have been applied on the other side.

Per-call timeouts add up, so the total is bounded only by the sum, not by what the user will wait. A deadline is one point in time passed down the chain: every hop computes the time remaining, so the whole request is bounded and any hop can fail fast when the time is already gone.

Attach cleanup to scope exit so it runs on success, failure and cancellation alike, release in reverse acquisition order, and run any blocking or awaiting cleanup inside a small shielded (non-cancellable) region with its own timeout — otherwise a sticky cancellation aborts the cleanup itself. Never shield the whole task.

Pick the first genuine failure as the primary cause, attach the second as a suppressed or secondary cause, and drop the cancellation errors entirely — they are consequences of the first failure, not causes. Keep each error's identity (which child) and never let a wrapper hide the type callers catch on.

Attempts multiply: worst case is over 6 seconds against a 3-second promise, so attempts 2 and 3 run after the caller has already given up — pure wasted load. Fix: retry inside the remaining deadline, set each attempt's timeout to min(cap, remaining), and skip retries when too little time is left.

Cancelling a node marks it and recursively signals every descendant, and tasks spawned afterwards start already-cancelled. Each leaf stops at its next checkpoint and cleans up. Cancellation is complete only when the whole subtree has terminated, so the parent must wait — with a grace deadline and escalation for stragglers.

Separate the completion policy from the structure: make each child's failure a value rather than an escaping error, so the scope decides. Common policies are all-succeed, any-succeed, k-of-n quorum and best-effort-by-deadline. The scope still owns and joins every child, and partial results must be labelled as partial.

Because release is tied to the region, not the task. When the region ends it closes or recycles the resource, and the surviving task keeps using it — writing into a buffer or connection now owned by someone else. That is corruption and cross-request data leakage, not just a crash.

A supervisor watches its children's outcomes and applies a policy: resume (keep state, log), restart (discard possibly corrupt state, start from a known-good initial state), stop (the child is no longer viable), or escalate (fail itself so a higher supervisor recovers a bigger subtree). Bound restarts with a budget and backoff.

Give them a longer-lived owner instead of no owner. Each background task belongs to an explicit component or application-lifetime scope that starts it, watches its failures, and cancels and joins it in a defined shutdown order. Ownership moves up the tree; it never disappears.

Start from the user-visible budget and divide it downward: subtract fixed overhead and a cleanup reserve, split the rest across sequential hops, share it among parallel ones, and propagate the remainder as a deadline every hop enforces and sheds on. Size each hop from its measured p99, not from a guess.

If a request is still pending at roughly the p95 latency, send a duplicate to another replica, take whichever answers first, and cancel the loser. It cuts tail latency when slowness is per-request bad luck, and costs about 5% extra load plus a strict idempotency requirement.