In a web framework, why can an error inside work a handler scheduled to outlive it escape the middleware chain?

Everything a middleware chain does about failures rests on one assumption: the failure happens **while the chain is still waiting**. Hooks enclose a call; a failure of that call unwinds through them. Deferred work breaks the assumption, and that is why an error can happen during a request and yet appear in no request log, no error-rate metric and no shaped response. ## The chain wraps a call, and only that call In a blocking execution model, each hook is a live frame for exactly as long as the inner call runs. The instant the innermost call returns, the frames pop and the opportunity to unwind through them is gone. In a non-blocking model the handler returns almost immediately, handing back a value that represents eventual completion. The chain is built over that value: each element composes its own after-work and failure-handling onto it, and a failed completion travels back along the same composition. The unwind is not a stack unwind any more, but the rule is identical — **the failure must be carried by the thing the chain is waiting on**. | What the handler does with the work | Does a failure reach the chain? | Why | |---|---|---| | Performs it before returning | Yes | the failure unwinds the live frames | | Returns the value representing it | Yes | the chain composes over that value | | Starts it and returns without it | No | the chain finished before the failure existed | | Registers it to run after the response | No | it runs outside the composed path | ## Where the error actually goes When work is detached, the failure has no in-request destination. Depending on the runtime it typically ends up in one of three places, none of which is the request path: - A **runtime-level last-resort hook** for failures nobody claimed, if the service installs one. This is the single most valuable thing to install early, because without it the class of bug is invisible. - A **warning on standard error**, easy to lose in volume and usually missing any request identifiers. - **Nowhere.** The failure value is dropped, and the only evidence is work that silently did not happen. A second, subtler consequence is context. Chains commonly set ambient per-request state on the way in and clear it in cleanup on the way out. Detached work runs after that cleanup, so reading the state later yields empty values — or, on a reused worker, values belonging to a different request. Anything the detached work needs must be **copied at scheduling time**, not read later. ## Designing for it 1. **Prefer not to detach.** If the work is part of the request's meaning, return it into the value the chain waits on. Then failures behave exactly like any other handler failure and every existing rule applies. 2. **Make detachment explicit.** When work genuinely must outlive the request — a notification, a slow cleanup, a cache refresh — route it through one named place rather than ad hoc scheduling scattered through handlers. A single place is somewhere you can attach the boundary once. 3. **Give detached work its own boundary.** Catch everything inside it, log with the request identifiers copied at scheduling time, and report to the same sink the request path reports to. 4. **Count it.** A metric on detached-task failures is the only thing that turns this from an invisible class of bug into an alertable one. 5. **Bound it.** Detached work with no timeout and no concurrency limit accumulates under load, long after the requests that started it have been answered. 6. **Consider durability.** If losing the work is unacceptable, in-process detachment is the wrong mechanism; the work belongs in something that survives a restart. ## Why interviewers like this one It separates people who have only read about middleware from people who have operated it. The chain's guarantees look total until you notice they are scoped to one call, and the systems that get burned are exactly those that moved slow work off the request path for good latency reasons without moving the error handling with it. A strong answer states the scope rule in one sentence, names the two execution models without claiming they behave differently in principle, and then goes straight to the operational consequences: no report, no context, no limit.