Structured concurrency cancels siblings that already succeeded, not just the one that failed

The lesson

When one task in a structured-concurrency group throws, every sibling task is cancelled immediately — not failed on its own terms, cancelled. This includes siblings that had already done real, salvageable work that a later step was consuming incrementally (a writer that had already flushed several successful items into a stateful, order-dependent output). A generic catch (Exception) (or equivalent) wrapped around such a sibling will also catch the cancellation signal, because in most runtimes "this scope is shutting down" is implemented as a subtype of the ordinary exception hierarchy, not a separate channel. The sibling's cleanup path then runs exactly as if it had failed by itself, discarding progress that had nothing to do with the actual failure. Net effect: one transient failure in one task throws away correct, finished work from every other task in the group, and whatever that group had built up has to be redone from scratch.

The failure that taught it

In a mobile app that downloads a series of remote files concurrently and incrementally muxes each into a single output container as it lands (order-dependent, one task consuming items produced by several others), the downloads and the muxer ran as sibling coroutines inside one structured concurrency block. A single download failing — one dropped connection among many, on an item unrelated to anything already muxed — cancelled the whole block, including the muxer mid-stream. The muxer's own error handling wrapped its loop in a general catch-and-clean-up, so it treated the cancellation the same as any other failure and discarded its output rather than distinguishing "my own work is fine, a sibling died." The underlying container format also could not be resumed once finalized or aborted, so every item that had already been correctly combined had to be redone from scratch on the next attempt — a full-series-length reset triggered by one item's transient, otherwise-harmless failure.

How to apply it

• Before wiring independent-but-order-dependent tasks into one structured-concurrency scope, ask specifically: "if task B throws, what does the cancellation of task A look like, distinct from A failing on its own?" A generic catch block almost never makes that distinction, and will treat cancellation-of-a-healthy-task the same as a real failure unless written to check for it.
• If a sibling task holds state or output that represents progress worth keeping (a partially written file, a partially filled cache, a partially sent batch), either give it a cancellation-aware path that preserves what is already done, or avoid putting it in the same cancellation scope as producers that can fail independently of it.
• Prefer fixing the root cause at the leaf — retry the actual flaky unit (a network call, a remote fetch) — so group-cancellation is rarely exercised in the first place, rather than trying to make every sibling gracefully survive being cancelled mid-work. Retrying one item is almost always simpler than making a stateful accumulator resumable.
• Recall this while designing a pipeline where one stage feeds items to another as they complete inside a single task group, or when a retry after a partial failure is doing far more work than the one piece that actually broke.