When a request passes through a chain of interceptors around one call, in what order do their after-the-call parts run?

## Handlers nest; they do not queue An **interceptor chain** is a set of handlers placed around a single call so that each may run work before the call reaches its **target**, work after a result comes back, or both. The common wrong picture is a list processed top to bottom. It is a **nesting**: assembling the chain hands each handler a reference to the rest of the chain, and the innermost reference is the target itself. A wrapping handler therefore has four moments, always in this order: 1. work before it passes control inward; 2. the inward call, which runs everything nested inside it; 3. work after that call returns, using whatever came back; 4. the value it hands outward to the handler that called it. A handler that has only the first moment is a pure pre-step. One that has only the third is a pure post-step. One that has both genuinely *wraps* the call, and only that shape can measure, retry, or replace what happened inside. ## Entry is outermost-inward; return is innermost-outward Take a chain of four handlers around one target: authentication, quota, timing, retry. Entering, the before-parts fire in assembly order - authentication, quota, timing, retry - and then the target runs. Returning, the after-parts fire in the exact reverse - retry, timing, quota, authentication - because each handler resumes only when its own inward call has come back. With `n` handlers in front of the target, `n` frames are open while the target executes, one per handler that has proceeded and not yet resumed. That is the whole mechanism; everything else follows from it. | moment | runs in | what the handler still controls there | |---|---|---| | before proceeding | assembly order, outermost first | the arguments it passes inward, and whether the call continues at all | | after proceeding | reverse order, innermost first | the value it hands outward, and whether a failure keeps travelling | ## What position therefore decides - A handler sees the target's own return value only when no handler nested inside it replaced that value first. - A handler placed outside a retrying handler is entered once per request; one placed inside it is entered once per attempt. - After-work runs only when control actually returns through that handler, which is why a short-circuit or a failure can skip it. - Two handlers that both log will interleave as a matched pair of brackets, not as two independent sequences. - Reordering two handlers changes both phases at once: swapping their before-parts necessarily swaps their after-parts the other way. - The outermost handler is the last thing the caller's result passes through, which is what makes it the right place for a translation the caller must see. ## Three shapes that bend the picture - **A handler that never proceeds.** Nothing nested inside it runs at all, yet the handlers outside it already ran their before-parts and still run their after-parts, seeing the substituted value as though the target had produced it. - **A failure instead of a value.** The unwind still travels outward, but a handler's after-work is skipped unless that handler explicitly deals with the failure, so the ordering rule holds while the work each handler does changes. - **A result that has not completed yet.** If the inward call hands back a pending result rather than a finished one, work written after the inward call runs when the chain was *assembled through*, not when the operation finished. Some runtimes give you a way to attach the after-work to completion instead; the point is that the frame-based ordering above describes a synchronous return, and a pending result must be handled deliberately. ## How to answer it in an interview Say the three things in order: handlers nest, entry runs outermost-inward, return runs innermost-outward. Then give one consequence you have actually seen - a duration that turned out to cover more than you thought, a log line that appeared after another you expected it to precede, a value the outer handler saw that no longer matched what the target returned. Interviewers ask this because almost every framework behaviour that looks like magic - transactional boundaries, request logging, quota accounting, latency metrics - is one nesting decision, and a candidate who can draw the nesting can predict all of them without reading that framework's manual.