How does a server-side web framework notice that the client aborted the connection before the response was finished?

## What a client abort is A client abort is the client ending the exchange before the response has been fully delivered — a browser tab closed, a user navigating away, an upstream proxy hitting its own deadline, or a caller giving up and closing its connection. From the server's side it arrives as a transport-level event: the peer half-closed or reset the connection. The framework's job is to turn that low-level event into something a handler and an operator can act on. ## The two shapes a framework gives it | Shape | How the server learns | Who it helps | |---|---|---| | Write failure (passive) | The next attempt to flush bytes fails with a broken-pipe or connection-reset error | Handlers that are actively writing — a streamed body sees it on the next chunk | | Disconnect event or cancellation signal (active) | The connection is monitored; the close triggers a callback, an event, or the request's cancellation signal | Handlers that are computing or waiting, and downstream calls that can be cancelled | The distinction matters because the passive shape has a blind spot. A handler that builds a large response in memory and writes it in one go performs no intermediate write, so it discovers the abort only when it finishes and tries to send — after all the expensive work has been done. That is precisely the case where the active shape saves capacity: the signal arrives while the work is still in progress, and the same propagation rules apply as for a timeout, so the abort can cancel the downstream calls the handler is waiting on. ## What a handler should do with it 1. **Stop producing.** Abandon the remaining chunks, the remaining pages, the remaining computation. Nobody will read them. 2. **Release what it holds.** Close cursors, return connections, delete partial temporary files. A disconnect exits the handler on an unusual path, so the cleanup must not live only at the bottom of the happy path. 3. **Decide about side effects explicitly.** If the handler has already committed a write, the client never saw the confirmation. Whether to keep, undo or record that outcome is a domain decision, and the abort is the moment it becomes visible. 4. **Do not treat it as a server failure.** The server did nothing wrong; the reader left. ## Why aborts distort operations - **Error budgets get polluted.** If broken-pipe failures are mapped to 5xx and alerted on, a spike of users closing tabs looks like an outage. Count aborts on their own dimension. - **Traces end abruptly.** A span that terminates with a write failure looks like a crash unless the framework labels the client-abort case distinctly. - **Work continues invisibly.** Without an active signal, a long report keeps being generated for a reader who left ten seconds ago. Under load this compounds: the users most likely to abort are the ones being served slowly, so the system spends its scarcest capacity on responses that will never be read. - **Retries multiply it.** A caller that aborts and immediately retries doubles the work unless the original request is cancelled, which turns a slow endpoint into a self-amplifying one. ## Limits worth knowing - Detection is **not instantaneous and not guaranteed**. A client that vanishes without closing cleanly — a dropped network, a powered-off device — leaves the server holding a connection that looks open until some lower-level keep-alive or idle bound decides otherwise. - Detection also **cannot be retroactive**. Once bytes are on the wire they are gone; noticing the abort lets the server stop, not take anything back. - Connection reuse changes the picture. Where many exchanges share one connection, the end of one exchange is not a connection close, so an abort is a per-exchange notion the framework must expose per request rather than per socket. The answer an interviewer is listening for is the pairing: **a write failure tells a writer, a signal tells a thinker**, and only the second one stops work that has not reached its first flush.