In a web framework's middleware chain, what happens if an element never invokes the rest of the chain, and what if it invokes it twice?

## The contract An element in a wrapping chain is trusted with the whole remainder of the pipeline. Normal behaviour is **exactly one** delegation call, its result returned outward. The framework cannot enforce that, because delegation is an ordinary function call in code you wrote, so both deviations are yours to prevent. | | Missed delegation | Double delegation | |---|---|---| | Handler invocations for one request | zero | two | | What the client sees | a default or empty response, or a timeout | one response, normally the first | | Typical damage | the request is never served, resources stay held | duplicated side effects and doubled metrics | | Where it hides | a rarely taken branch that returns early | a branch that calls, then falls through to a shared call | | How you notice | an endpoint that silently does nothing | duplicate rows, duplicate messages, halved-looking success rates | ## When the call never happens Two situations look identical in the code and are completely different in intent. An element may return without delegating **because it has already produced the answer itself**, which is a legitimate move with its own rules. The bug is returning without delegating **and** without producing anything. What the caller experiences then depends on the execution model: - Frameworks that treat a finished chain with nothing written as a result in its own right synthesise something, often an empty success or a not-found style answer. The response is fast, wrong, and gives no hint that an element ate the request. - Frameworks that expect the response to be written before the exchange completes may simply keep it open. The connection, and in a thread-per-request model a worker, stay occupied until a client or server idle timeout fires. The tell is a latency graph pinned exactly at the timeout value. The usual causes are ordinary code shapes rather than exotic mistakes: 1. A guard that logs a suspicious request, was meant to continue, and returns instead. 2. A conditional where one branch delegates and the other silently falls off the end. 3. A refactoring that moved the delegation call into a helper which is not reached on every path. 4. In deferred-result models, calling the remainder but not returning or composing its result, so the outer elements believe the work is finished when it has barely started. ## When the call happens twice A second delegation re-enters everything inside this element, including the handler. The handler has no way to tell it is running for the second time, because from its point of view this is a normal invocation of a normal request. - **Side effects double.** Two rows, two charges, two outbound messages. This is the real damage, and it is the element's fault, not the handler's. - **The response usually rejects the duplicate.** The second pass tries to produce a response that has already been produced, so the framework raises an error or discards the extra output. Only one response reaches the client, which is why the wire gives no clue. - **A one-shot request body is empty the second time.** Request bodies are frequently streams that can be read once, so the replayed pass sees nothing and the handler answers with a confusing validation failure. - **Inner state is counted twice.** Metrics, rate-limit counters and acquired resources inside the chain all see two passes for one client request. The classic code shape is not a deliberate second call but a fall-through: a branch that delegates and then continues into a shared delegation statement at the end of the body. ## Is replaying the remainder ever legitimate? Rarely, and only with three guarantees in place: nothing has been written to the client yet, so the element must be buffering the response rather than letting it stream; the request body is replayable, which normally means it was captured in memory first; and the inner work is idempotent or the element knows exactly which side effects it is repeating. A middle position in a server-side chain can seldom promise all three, which is why retrying belongs at boundaries that can, such as an outbound client, rather than inside the request pipeline. ## Making both failures visible 1. **Test every branch of every element**, asserting that the inner callable was invoked exactly once, using a stub that counts invocations. This is the only check that catches a forgotten call on a rare path. 2. **Make the call the last statement** on each path, or structure the body so there is a single delegation point, so a fall-through cannot reach a second one. 3. **Compare counters**: requests entering the outermost element against handler invocations. A persistent gap means requests are being eaten; a persistent excess means something is replaying them. 4. **Watch for timeout-shaped latency.** A cluster of requests completing at exactly the client timeout is a strong hint that something stopped delegating on a particular path.