In a product-page pipeline, what happens to the formatting stages between a failing price lookup and a recovery step placed last?
answer
- two kinds of signal, two paths
- value stages ignore a failure
- distance decides what is skipped
- the fallback enters below them
- fallback must already be final shape
basics
~20 sNothing runs in them. A failure signal travels past every stage that only handles values, so the formatting stages are skipped and the substituted value enters the sequence below them — it must therefore already be in the shape the subscriber expects.
solid answer
~40 sStages that transform values are involved only when a value passes through; a failure signal passes them untouched and keeps travelling until something matches it. So a price lookup that fails at the top of the chain skips every formatting stage between it and the recovery step at the bottom. The practical consequence is about **shape**: the fallback the recovery step supplies is injected *below* those stages, so no tax calculation and no display formatting is applied to it. Either you write the fallback already formatted, or you attach the recovery step upstream of the formatting so the substituted value re-enters above it and is processed like a real price.
code
pseudocode · 7 linespage = fetchPrice(id) // fails here
.mapEach(price => applyTax(price))
.mapEach(price => formatForDisplay(price))
.recoverWithValue("price unavailable") // fallback enters here
// the failure passes through both mapEach stages untouched;
// "price unavailable" is never taxed and never formattedgo deeper
Remember that a failure and a value take different paths: a stage written to transform values is simply not involved when a failure travels past it.
Explain why the fallback must already be in final shape — it enters the sequence below every stage between the failure and the recovery step, so none of them touch it.
Diagnose it from the symptom: a fallback that renders untaxed or unformatted beside correct neighbours is the signature of recovery placed too far downstream, not of a bad default value.
Decide the convention: whether pipelines recover next to each failing stage or once at the edge, and what each choice implies about where default shapes are owned and reviewed.
## Two kinds of signal, two different paths A stream carries **values** and one **terminal signal**. A stage such as `applyTax` or `formatForDisplay` is written against the value path: it is given a value and asked to produce another one. When a failure signal reaches it, there is no value to transform, so the stage has nothing to do — it forwards the failure and is finished. That is the mechanism behind the whole answer. A failure does not stop at the next stage; it **travels down the chain** until it meets a stage that is looking for it. Everything between the point of failure and that stage is skipped. ## Distance decides how much is skipped The interviewer's real subject is placement, not the recovery step itself. Where you attach it decides three things at once. | Recovery attached… | What it replaces | Which stages still run on the fallback | Shape the fallback must have | |---|---|---|---| | Immediately after the failing price lookup | The rest of the price sub-result | Every formatting stage below it | The raw shape a price lookup returns | | Halfway down, after the tax stage | The remainder from that point on | Only the stages below the attachment point | The shape the tax stage would have produced | | At the very end of the pipeline | The remainder of the whole pipeline | None | The final shape the subscriber consumes | Read the last row carefully: a recovery step at the end is the most convenient place to write one and the place where the fallback carries the most obligations, because it must impersonate the output of every stage it skipped. ## What this looks like as a bug The symptom is not an exception. It is a page that renders, and renders wrong: - A fallback price shown without tax, because the tax stage never saw it. - A fallback shown unformatted — raw units, no rounding — while every real price beside it is formatted. - A default that is correct in isolation but inconsistent with its neighbours, because the neighbours went through stages the default skipped. - A field the enrichment stage was supposed to populate arriving empty on the fallback only. Each of those is diagnosed the same way: the fallback entered the sequence below the stage whose work is missing. Fixing the fallback value is treating the symptom; moving the recovery step upstream fixes the cause when the fallback genuinely should be processed like a real price. ## The two placements, stated as a rule 1. **Recover late** when the fallback is a whole, finished answer — an entire substitute page, a complete empty result. Nothing downstream needs to touch it, and one recovery step covers every failure the pipeline can raise. 2. **Recover early**, next to the failing stage, when the fallback is raw material that the rest of the chain should still work on, or when the stages below it are doing work you do not want to lose. 3. **Never** assume it makes no difference. A recovery step is not a global handler bolted onto a pipeline; it is a stage, and stages have positions. ## When two recovery steps sit in one chain A failure is matched by the **first** recovery step it reaches that accepts it. A later one in the same chain sees nothing and never fires — unless the earlier one substituted an alternative source and that source fails in turn, in which case the new failure carries on from that point and can be matched further down. This is why stacking recovery steps 'to be safe' gives a false sense of coverage: the lower ones are usually dead code for the failure you were worried about. ## The order you cannot see One more subtlety belongs here. The stages are arranged when the pipeline is **assembled**, before anything subscribes, and that written order is the order signals travel at run time. So the placement question is answered in the source text, statically, and can be reasoned about without running anything: read down the chain from the stage that can fail, and the first recovery step you meet is the one that will handle it — with everything in between skipped. That static reading is the skill being tested. An engineer who can point at a chain and say 'this failure is caught here, and these three stages never run' has the model; one who describes recovery as 'catching the error' without saying where the fallback re-enters does not.
- Where must the recovery step sit so that its fallback price goes through the same formatting as a real one?Upstream of the formatting stages — attached directly to the price lookup. The substituted value then enters the sequence above them and is taxed and formatted like any real price. Attached at the end, it enters below them and you must produce the finished shape yourself.
- If two recovery steps sit in the same chain, which one handles a failure raised above both?The first one the failure reaches that accepts it; the second never sees that failure. The lower one fires only if the upper one substituted an alternative source and that source then fails, producing a new failure from that point downward.
A parcel marked undeliverable is handed straight to the returns desk, skipping every sorting station on the way — which is exactly why the returns desk has to hand back something already boxed and labelled.
saying these in an interview costs you the question
- Thinks the mapping stages run on the substituted value before delivery.
- Believes a recovery step can sit anywhere without changing the result.
- Expects enrichment written below the failing stage to still be applied.
- Says recovery resumes the pipeline at the stage that failed.
- Treats the failure as skipping only the stage that raised it.