You start three concurrent child tasks and wait for all of them. One fails after 50 ms while the others would run for another 10 seconds. What should happen to the siblings, and why is that the default in structured concurrency?

## The situation A scope starts children A, B, C and its contract is "give me all three results". At t=50 ms, B throws. The scope's result is now determined: it cannot produce all three, so it will fail. The only remaining question is what to do with A and C. ## Three possible behaviours 1. **Wait for everyone, then report.** The scope lets A and C run to completion (10 s), then raises B's failure. Correct, but the caller waited 10 seconds for an answer known at 50 ms, holding a request slot, connections and memory the whole time. Under a 2-second client timeout, the caller has already given up and the work is pure waste. 2. **Report immediately, leave siblings running.** The caller gets the error at 50 ms but A and C are now orphans: still holding pooled connections, still issuing outbound calls, still able to write. The caller sees a failed request while side effects continue behind it, and shutdown cannot account for them. 3. **Fail fast: cancel siblings, join them, then report.** Signal A and C, wait for them to reach a checkpoint and clean up, then propagate B's failure. Latency is 50 ms plus the wind-down; no orphans remain. Structured concurrency chooses (3), because (1) wastes time and (2) breaks the ownership invariant that no task outlives its scope. ## Why fail-fast is the right default - **The result is already decided.** With an all-must-succeed contract, continuing sibling work is provably useless. Spending resources on a computation whose output will be discarded is the definition of waste. - **Latency compounds.** In a fan-out tree, waiting-for-everyone at each level multiplies: the request's latency becomes the maximum across every branch even when a failure at one leaf doomed the whole thing early. Fail-fast collapses it to the *first* failure. - **Failure locality.** Because the scope propagates the error at its exit, the caller sees it in its own stack with its own context, and existing try/catch, retry and fallback logic applies unchanged. There is no separate asynchronous error channel to remember to wire up. - **Bounded resource use.** Connections, file handles and memory held by doomed siblings are returned at the moment the outcome becomes known. - **Shutdown correctness.** Joining the cancelled siblings means that when the caller receives the error, the concurrent work is genuinely over — nothing continues to mutate state behind an error response. ## The mechanism, and what it costs Fail-fast is a *policy* implemented with cancellation as its *mechanism*: the failure propagates upward to the scope, and the scope propagates cancellation downward to the remaining children. Because cancellation is cooperative, the scope's total time is: **time-to-first-failure + max over surviving siblings of (checkpoint gap + cleanup)** So a sibling with no checkpoints, or with an unbounded shielded cleanup, erases most of the benefit: you fail fast in intent but still wait ten seconds in practice. Fail-fast is only as fast as the siblings are cancellable, and a grace deadline with escalation is needed for the pathological cases. ## Details that trip people up - **The scope must still join.** Cancelling and returning immediately is behaviour (2) in disguise. "Fail fast" means fast to *decide*, not skip the wait. - **Which error do you report?** The first observed failure is the natural primary cause. The cancellations that follow are consequences and must not be reported as the reason — otherwise every incident log says "cancelled" and the real cause is hidden. When two children fail genuinely independently, both should be preserved rather than one silently dropped. - **Side effects already committed are not undone.** Cancelling A stops future work; it does not roll back the row A already wrote. If the operation needs atomicity across children, you need compensation or an idempotent retry path — fail-fast is not a transaction. - **Retries interact.** If a child is internally retrying a transient error, the scope may cancel it mid-retry. That is usually correct, but it means the sibling's own retry budget is subordinate to the scope's outcome, which should be a conscious decision. ## When fail-fast is the wrong default Whenever the contract is not all-must-succeed: querying several replicas where the first success suffices; aggregating optional enrichments where a missing one just degrades the response; scatter-gather with a quorum; best-effort collection under a deadline. Those need a deliberately different completion policy in which a child's failure becomes a *value* rather than an escaping error. The structure — scope owns children, scope joins them, no orphans — stays identical; only the policy changes.