Some concurrent work legitimately outlives any single request — background schedulers, cache refreshers, connection keep-alive loops, metric flushers. How do you reconcile that with a discipline that forbids orphan tasks?

## Restating the rule correctly Structured concurrency is often summarized as "tasks must not outlive the function that started them", which makes daemons look like a contradiction. The precise invariant is weaker and more useful: **every task has an owning scope that will eventually join it, can cancel it, and receives its failures**. Nothing in that requires the owner to be a request. Long-lived work needs a long-lived owner. ## Build a lifetime hierarchy Make the lifetimes explicit and nested, largest first: ```text application scope (process lifetime: schedulers, metric flushers) └ component scope (module/subsystem: cache refresher, pool keep-alive) └ connection scope (one client session: reader loop, heartbeat) └ request scope (one call: fan-out children) ``` Each task is started in the scope matching its intended lifetime. A cache refresher does not belong to the request that happened to trigger a miss; it belongs to the cache component. This single placement decision fixes most "why is this still running?" incidents, because it is now answerable by construction. ## Ownership of data must move with the task Promoting a task to a longer-lived scope is only sound if it stops depending on shorter-lived state. A background task must not capture a request-scoped context, a pooled connection, or a mutable object the request thread will keep changing. Hand it **owned copies** of the values it needs (ids, immutable snapshots) and give the long-lived scope **its own resources** — its own connection or client, its own identity or service credential rather than the triggering user's. If a background task needs the caller's authority, that authority must be materialized into something with a matching lifetime, not borrowed. ## Shutdown is the real design work A long-lived scope's contract is exercised exactly once: at shutdown. Decide and write down: - **Order.** Generally stop accepting new work at the edge first, drain request scopes, then component scopes, then application scope — reverse dependency order, so a task is never cancelled while something still depends on it. - **Grace budget.** Each level gets a bounded time to finish in-flight work; the total must fit the platform's kill timeout (an orchestrator's termination grace period), otherwise the process is killed mid-drain and you get exactly the truncated-work failure the discipline was meant to prevent. - **Escalation.** Request politely (cancel), then hard-cancel, then abandon and log with the task's name. An unstoppable task must be *visible*, not silently waited on forever. - **Idempotent, bounded cleanup.** Cleanup runs when the deadline has already expired, so it needs its own small budget and must be safe to run twice. ## Supervision: a dead daemon is an orphan too If a long-lived task fails and nobody notices, you have re-created silent failure inside a scope. The owning scope must have a policy: restart with backoff and a failure budget (with a cap, so a permanently broken dependency does not become a hot loop), or mark the component unhealthy and fail readiness so traffic drains away. Either way the failure is *reported* — counted, logged with the scope name, and visible in health checks. "Restart forever, log nothing" is the anti-pattern. ## Bounded concurrency and observability Long-lived scopes are where unbounded growth reappears, because request scopes no longer bound it: a component scope that starts one task per incoming item will happily accumulate millions. Cap it — a fixed worker set consuming a bounded queue, with an explicit policy when the queue is full. And expose the tree: a debug endpoint or dump listing live scopes, their names, child counts, and ages turns "something is still running" into a one-line answer, and makes leaked lifetimes obvious in staging. ## Handing tasks upward Some runtimes let a task be *moved* to an ancestor scope rather than being started there — useful when a request discovers work that must continue after it returns. That is the sanctioned escape hatch: ownership is transferred, never dropped. If your platform lacks it, model the same thing explicitly by submitting a self-contained job (owned data only) to a component-scoped worker. ## The acceptance test At any instant, for every live task, you can name the scope responsible for it, the deadline or cancellation signal that will end it, and where its failure will be reported. If any of the three is "nowhere", it is an orphan wearing a costume.