What goes wrong when a handler re-enters the same interceptor chain while that chain is still running?

## What re-entry is - and what it is not **Re-entry** is control that is already inside a chain arriving at that chain's outermost handler again, so the entire nesting runs a second time within the first. It typically happens when a handler, or code the target reaches, goes back through the same guarded entry point: a handler that resolves something by issuing another guarded operation, a retrying handler layered over an entry point that is itself guarded, or a chain assembled in a loop where the innermost reference points back at the head. It is worth separating from the opposite situation - a call that never enters the chain at all, which is a different subject. Here the chain does not fail to run; it runs **more times than the design assumed**. ## What runs twice Every handler between the chain head and the target is entered again. Concretely, for a chain of authentication, quota, timing and the target: 1. The outer run's before-parts have all fired; four frames are open. 2. Something inside triggers re-entry at the head. 3. Authentication, quota and timing run their before-parts a second time and the target runs again. 4. The inner run unwinds fully. 5. The outer run resumes and unwinds - now with whatever the inner run left behind. The symptoms follow mechanically: - **Accounting is charged per entry, not per logical operation.** A budget decremented in the before-part is spent twice for one request. - **Measurements nest.** The outer sample fully contains the inner one, so summing samples double-counts, and a naive total exceeds the elapsed time of the request. - **Ordering guarantees still hold within each run**, which is why the logs look correct locally and wrong in aggregate: a perfectly matched set of brackets, just twice as many as there were requests. - **A stopping handler may refuse the inner run** even though the outer run was admitted, so the failure surfaces in the middle of an operation that had already been approved. ## The state trap The sharpest failure is state. A handler that stores per-call information in a field it owns - a start time, a captured argument, an accumulated tally - is assuming it is entered once per call. Under re-entry the inner run overwrites that field before the outer run reads it, so the outer run's after-work uses the inner run's data. The measurement is then not merely doubled; it is wrong in a way that no amount of arithmetic recovers. | where the handler keeps per-call state | behaviour under re-entry | |---|---| | a field on the handler itself | overwritten by the inner run; the outer run reads the inner values | | a local in the handler's own frame | correct, because each run has its own frame | | a context object carried with the call | correct, provided the inner run gets its own context | | a stack of contexts keyed by depth | correct, and lets a handler see that it is nested | ## Detecting and bounding it - **Carry per-call state on the call or in a frame local**, never in a field the handler reuses. This alone removes the worst class of the bug. - **Mark depth.** A marker carried with the call lets a handler ask whether this is an outer or a nested run and skip work that must happen once - charging a budget, starting an outer measurement, emitting an audit record. - **Decide which handlers are idempotent per entry.** Some genuinely should run on every entry, such as a check that must hold for every operation; others must run once per logical request. Making that distinction explicit is the design work. - **Enter inward, not at the head,** when a handler needs to issue a related call that should not be re-decorated. Continuing from the current position rather than restarting at the head keeps the nesting depth flat. - **Bound it.** An unconditional re-entry is unbounded recursion, and the only reliable signal is a depth limit that stops the chain with a diagnosable failure rather than an exhausted stack. ## Why an interviewer asks this It separates candidates who have only read the happy path from those who have debugged one. The tell-tale evidence is characteristic: durations that sum past wall-clock time, budgets exhausted at half the expected traffic, a perfectly structured log that contains exactly twice as many brackets as there were requests. A candidate who can name the mechanism - the chain entered again from inside itself - can diagnose all three from one of them.