Failure Propagation¶
Error propagation — instantiates Deferred Fulfillment Placeholder
Routes a placeholder's failure — with its reason preserved — to every dependent, switching each to its fallback instead of leaving it to hang.
Failure Propagation is what happens when a placeholder resolves to failed rather than fulfilled, and the bad news has to travel. Its job is to take a producer's error — a genuine inability to supply the promised value — and route it, with its reason intact, to every dependent that was counting on that value, so each can react rather than wait forever. Its defining move is preservation-and-routing of a fault: the failure is a real terminal outcome the producer hit (a rejection, an error, a broken dependency), and this mechanism keeps its cause attached as it flows outward and steers each dependent onto its fallback path. It is distinct from a deliberate cancellation (nobody chose to stop; the value simply could not be produced) and from a mere timeout (an answer came — it was "no").
Example¶
A factory building electric bikes has a pending-delivery placeholder for a batch of motor controllers from a supplier. Mid-week the supplier's line goes down and it declares it cannot ship — the placeholder resolves to failed, with a concrete reason: "controller firmware recall, no stock for three weeks." Failure Propagation carries that outcome, reason and all, to everything downstream that had planned around those controllers. The final-assembly work order sees failed: firmware recall and does not sit idle pretending parts are still "on the way." The QA schedule that was reserved for that batch is released. The purchasing system, seeing the failure and its reason, triggers each dependent's fallback path: source the controllers from the qualified second supplier at higher cost.
Because the reason rode along with the failure, the fallback is intelligent — purchasing switches to the backup supplier specifically because it was a stock-out, not, say, a price dispute that a different response would suit. Nothing hangs, and no downstream step mistook a dead promise for a live one.
How it works¶
- Settle the failed terminal state. Confirm the placeholder has resolved to
failed(as distinct from cancelled or expired) so the propagation carries the right kind of ending. - Preserve the failure evidence. Attach and carry the reason — error code, message, offending input — so dependents learn why, not merely that, it failed. Losing the reason is a named failure of the archetype.
- Fan the failure to dependents. Walk the dependent set and hand each the failed outcome plus its reason, so no dependent is left waiting on a value that will never come.
- Trigger fallback paths. For each dependent that registered one, switch it onto its alternate value or recovery route; for those that didn't, surface the failure so it is handled, not swallowed.
It reports and routes a fault; it does not decide who was allowed to cause it, and it is not the one holding the token of a deliberate cancel.
Tuning parameters¶
- Reason fidelity — how much of the failure's cause is carried: a bare error flag, a typed error, or a full diagnostic chain. Richer reasons enable smarter fallbacks but can leak internal detail across boundaries.
- Fan-out policy — fail all dependents at once, or fail them lazily as each next touches the placeholder. Eager keeps everyone consistent; lazy avoids waking dependents that no longer care.
- Fail-fast vs. contain — whether one placeholder's failure aborts a whole dependent computation immediately, or is contained so siblings can still succeed. Fail-fast is simple; containment preserves partial progress.
- Fallback aggressiveness — whether to auto-switch dependents to their fallback, or fail them and let a human decide. Auto is fast; manual keeps a person in the loop for costly alternatives.
- Retry-before-propagate — how many times to retry the producer before declaring failure. More retries mask transient faults but delay the honest "no."
When it helps, and when it misleads¶
Its strength is that failures become first-class, routed events rather than silences: the Erlang/OTP habit of "let it crash" and route the exit to a supervisor[n1] is exactly this — a fault that propagates with its reason is one that can be handled, whereas a swallowed one strands everyone. Carrying the reason is what makes each dependent's fallback a considered response instead of a blind default.
Its failure mode is the lost failure reason: a placeholder that resolves to a generic error with no cause, so dependents know only that something broke and fall back blindly (or worse, retry the un-retryable). The mirror misuse is over-propagation — one non-critical failure fail-fasting an entire graph that could have contained it and carried on. The guarding discipline is to always propagate the reason with the failure, to distinguish transient from permanent faults before deciding retry-or-fallback, and to contain failures at the narrowest dependent boundary that still keeps the system honest.
How it implements the components¶
Failure Propagation fills the fault-routing components:
terminal_state_model— works specifically with thefailedending, keeping it distinct from cancelled and expired as it propagates.resolution_evidence_record— carries the failure's reason and provenance outward so dependents learn why it failed.fallback_value_or_path— switches each dependent onto its registered alternate value or recovery route in response to the failure.
It does not implement cancellation_token — a deliberately withdrawn (not failed) placeholder is Cancellation Propagation. A failure is a fault the producer hit; a cancellation is a decision someone made. It also does not own timeout_and_cancellation_policy, the deadline clock of Timeout Expiration Handler.
Related¶
- Instantiates: Deferred Fulfillment Placeholder — the mechanism that carries a failed outcome, with its reason, to dependents.
- Consumes: Resolution Event Commit — it propagates the
failedterminal state that the commit settles. - Sibling mechanisms: Cancellation Propagation · Timeout Expiration Handler · Resolution Event Commit · Callback or Continuation Registration · Promise Creation Protocol · Await or Subscription · Pending State Polling · Dependency Graph Scheduling · Resolved Value Memoization
Editorial Notes¶
Form Classification¶
Form family: Control, Automation & Runtime
Rationale: Failure Propagation operates as a live operational control that automatically routes, enforces, adapts, or responds during execution because it routes a placeholder's failure — with its reason preserved — to every dependent, switching each to its fallback instead of leaving it to hang.
Independent corroboration: The frozen evidence defines Failure Propagation as 'Routes a placeholder's failure — with its reason preserved — to every dependent, switching each to its fallback instead of leaving it to hang', so its operative form is Control, Automation & Runtime.
Review outcome: Independent reviewer agreement; high confidence.
Origin Attribution¶
Primary origin: Computer Science & Software Engineering
Origin pattern: Single lineage
Present-day reach: Specialized
Rationale: Propagating promise or dependency failure with preserved error state and fallback is a software concurrency and exception-handling pattern.
Related originating lineages:
- Systems Thinking & Cybernetics — Cascade analysis and fallback state transitions materially shape system-level propagation behavior.
Review resolution: Both reviewers agree that computer_science is primary. I retain systems_cybernetics only as formative origin lineages; single_lineage is appropriate because the alternate domains informed practice without constituting independent ownership. Reach is specialized because the mechanism remains tied to a bounded professional technique, an applicability judgment kept separate from provenance. Encyclopedia synthesis is true because the exact generalized artifact is an encyclopedia-authored combination or refinement. No unresolved historical ambiguity remains after reconciling the secondary fields.
Encyclopedia synthesis: The exact catalogued form synthesizes established practice rather than reproducing a single standard historical label.
Review outcome: Reconciled after independent review; high confidence.
Notes¶
[n1] Erlang/OTP supervision trees embrace "let it crash": a failing process propagates its exit to a supervisor that decides restart or escalation, so failures are routed and handled, not silently swallowed — the posture this mechanism generalizes to deferred values. ↩