When a stock-check stream fails and a recovery step substitutes an empty result, what does the subscriber then receive?

## What a recovery step replaces A stream delivers two kinds of signal to its subscriber: any number of **values**, followed by exactly one **terminal signal**, which is either a normal completion or a failure. A recovery step is a stage in the chain that watches for the failure signal and, when it matches one, does not pass it on. In its place it supplies a substitute for the **unfinished remainder** of the sequence. That phrase carries the whole answer, and it has three consequences worth stating separately: - The substituted empty result is emitted as an **ordinary value**, and the sequence then ends **normally**. The subscriber's failure path is never invoked for the failure that was matched. - Values the stock check had already emitted **before** it failed are untouched. They were delivered when they were produced; nothing withdraws them and nothing re-delivers them. - The work that failed is **not repeated**. Recovery does not go back to the stock check and ask again. Replacing a result and re-running the source that produced it are different mechanisms with different costs, and only the first one is recovery. ## The sequence, signal by signal 1. Something subscribes, and the stock-check source starts producing. 2. It emits whatever it managed to produce — say two items — and those travel straight down to the subscriber. 3. It fails. In place of a third value it emits a failure signal, and it is finished: it will produce nothing else, ever, on this subscription. 4. The failure travels downstream and reaches the recovery step, which matches it and stops it there. 5. The recovery step emits the empty result, then a completion signal. The subscriber's run therefore contained two real items, one empty result, and a successful ending. ## Substituting a value versus substituting a source Recovery comes in two shapes, and the difference is what the substitute *is*. Both stop the failure; they differ in what follows it. | The recovery step supplies | What the subscriber sees next | How the sequence ends | When it fits | |---|---|---|---| | A single ready value | That one value | Completion, immediately after it | A known-safe stand-in exists, such as an empty result | | Another source | Whatever that source emits, however many values | When the substitute source ends — normally, or with its own failure | A second, cheaper or cached provider can answer the same question | | A translated failure | Nothing | A failure again, but of a different, domain-meaningful type | The decision belongs to the caller, not to this stage | The third row is worth noticing because candidates often forget that a recovery stage may end a sequence in failure on purpose. Translating changes the **meaning** of the failure without inventing data. ## What the subscriber can and cannot tell - It cannot distinguish a genuinely empty stock result from a substituted one, unless the substituted value itself records that it is a stand-in. Both arrive as a value followed by completion. - It cannot tell how far the stock check got before failing, beyond counting the values it received. - It can tell that the run ended successfully — which is exactly the property that makes recovery useful and also the property that hides a real problem when the substitution is too broad. ## Partial delivery is the case people miss Because already-delivered values stand, a recovering sequence can hand its subscriber a **mixture**: some real items and then a fallback. If the subscriber accumulates those items into one page section, that section is now partly real and partly substituted, and nothing in the signals says which is which. When that matters, the substitute has to carry the fact of substitution in the value itself, or the recovery has to be attached where it replaces a whole sub-result rather than a tail of one. This is also why a substituted *source* needs a second look: it may emit a different number of values than the failed one would have, so a downstream stage that assumed exactly one value per request can be handed several, or none. ## Why the distinction from re-running matters Substitution is cheap and bounded: one value, delivered now. Re-running the failed work is neither, and it has a side effect the substitution does not — the work happens again. Keeping the two apart in your head is what lets you answer the next question an interviewer asks, which is always about placement: given that recovery replaces the remainder of a sequence, *which* sequence you attach it to decides how much of the pipeline that remainder is.