Why is a concurrent task that outlives the code region that started it dangerous when that region owns resources such as a pooled connection, a reusable buffer, a request-scoped context, or an open transaction?

## Resource management is scope-shaped Every mainstream resource discipline — block-scoped acquire/release, reference counting tied to a frame, `defer`-style cleanup — assumes one thing: **when the region ends, nobody is still using the resource**. In sequential code that is trivially true, because the region ending *means* all its work is done. Concurrency breaks the equivalence: the region can end while work it started is still in flight. ```text open(conn) # acquire spawn(task using conn) # escapes the region close(conn) # release while task still runs <-- unsound ``` The bug is not that the task is concurrent. It is that the *task's* lifetime is not contained in the *resource's* lifetime. ## The four classic victims **Pooled connections.** A pool's whole point is reuse: on release the connection goes back and is handed to a different request. A surviving task that writes to it is now injecting bytes into someone else's conversation. The observable symptom is a response delivered to the wrong client or a protocol desync — an integrity and confidentiality bug, not a crash. **Reusable buffers.** Buffers are pooled for the same reason. A late writer scribbles into memory another request is reading; a late reader sees another request's data. In a memory-safe language you get no fault, only wrong bytes. **Request-scoped context.** Tenant id, authenticated principal, locale, trace/correlation id — typically held per-request and cleared or reassigned at request end, often via a thread-local or task-local slot. A task that runs past that point either sees cleared context (nulls, missing tenant) or, worse, the *next* request's context, so it performs work under the wrong identity. That is an authorization defect. **Transactions.** A transaction has a strict lifetime bounded by commit or rollback. A task still issuing statements against a completed transaction gets errors at best; if the connection has been recycled it may run its statements in *another* request's transaction, so unrelated work commits or rolls back together. ## Why the failure mode is especially bad These defects are timing-dependent, so they appear at low rates under load and vanish under a debugger. They usually surface as **incorrect data rather than an exception**, so no alert fires — an audit row attributed to the wrong tenant, a response with someone else's payload. They cross request boundaries, which turns an ordinary lifetime bug into a security incident. And the stack trace, if you get one, points at the *victim* request, not the escaped task, so investigations start in the wrong place. ## Why defensive fixes are inadequate Tempting patches: copy the context into the task at spawn; add a reference count so the resource is not released until the last user drops it; check a validity flag before use. Copying context helps for immutable values only, and does nothing about pooled connections or buffers. Reference counting effectively re-implements joining, but without an owner to wait on it just delays release indefinitely when a task hangs, converting corruption into a leak. Validity checks race — the resource can be recycled between the check and the use. ## The structural fix Make the task a **child of the scope that owns the resource**. If the scope cannot exit until its children finish, then release, which happens at scope exit, provably occurs after the last use. Lifetimes nest, and the sequential acquire/release contract becomes sound again in a concurrent program. When work genuinely must outlive the request — say, a fire-and-forget audit write — the answer is not to let it escape, but to **move it to a scope whose resources it can legally hold**: hand it an owned copy of the data it needs, and run it under a longer-lived scope with its own connection and its own context, joined at shutdown. The rule of thumb is: a task may only use resources owned by an ancestor scope, never by a scope it has escaped. ## How it shows up in review Watch for a spawn inside a try-with-resources / using / defer block; for a task capturing a request context object; for "we fire this off and return" next to a pooled client; and for background work that reads a mutable object the request thread will keep mutating. Each is the same defect in different clothing.