Why asyncio.gather Errors Don’t Halt All Branches and How to Design Robust Failure Strategies

Understanding asyncio.gather’s Failure Propagation

By default asyncio.gather propagates the first exception to the awaiting task, but it does not automatically cancel the remaining awaitables; they continue to run. Treating gather as a “stop‑all‑tasks” primitive leads to a mistaken failure strategy.

Why Parallelism Is Not a Supervisor

Fan‑out expands a single task into multiple parallel branches, while fan‑in merges their results after all branches finish. A Supervisor, in contrast, makes semantic decisions that cannot be enumerated before runtime, such as adding new investigations or choosing a professional reviewer when evidence conflicts. The article argues that only when multiple legitimate next steps require semantic judgment should a limited Supervisor be invoked.

Failure Strategy Depends on Branch Criticality

Not every branch failure should be ignored. If a non‑essential branch (e.g., background news) fails, the system should mark the result as degraded rather than pretending success. If a required branch (e.g., policy version or order fact) fails, the overall workflow must be blocked.

Each branch should declare five attributes before dispatch: a stable branch ID, a required flag, input version, expected output schema, and allowed post‑failure actions. The fan‑in node then checks required artifacts, identifies optional gaps, and decides whether to block or degrade.

Choosing the Right Concurrency Primitive

When aggregating structured results, wrap each branch’s exception into a uniform Result object and then use gather to collect them. If any required branch fails and the whole group must abort, consider TaskGroup with fail‑fast semantics, where the first non‑cancellation exception cancels the remaining tasks.

External cancellation should propagate via CancelledError and be handled in a finally block; it must not be swallowed as a successful result. Retries are appropriate only for transient network errors and must have an upper limit.

Concrete Example Using Only the Python Standard Library

import asyncio
from dataclasses import dataclass

@dataclass
class Result:
    name: str
    required: bool
    ok: bool
    value: str = ''
    error: str = ''

async def worker(name, delay, required, fail=False):
    await asyncio.sleep(delay)
    if fail:
        raise RuntimeError(f'{name} failed')
    return Result(name, required, True, value=f'{name}:evidence')

async def safe_run(name, delay, required, fail=False):
    try:
        return await worker(name, delay, required, fail)
    except Exception as exc:
        return Result(name, required, False, error=str(exc))

async def run_case(required_fails):
    results = await asyncio.gather(
        safe_run('order', 0.01, True),
        safe_run('policy', 0.02, True, required_fails),
        safe_run('news', 0.03, False, True),
    )
    blockers = [r.name for r in results if r.required and not r.ok]
    gaps = [r.name for r in results if not r.required and not r.ok]
    if blockers:
        return f"BLOCK:{','.join(blockers)}"
    if gaps:
        return f"DEGRADED:{','.join(gaps)}"
    return 'READY'

async def main():
    print(await run_case(False))
    print(await run_case(True))

asyncio.run(main())

Running the script yields:

DEGRADED:news
BLOCK:policy

The first run shows only the optional news branch failed, so the system continues with a degraded flag. The second run shows a required policy failure, which blocks further processing despite the order branch succeeding.

Result Merging and Conflict Resolution

When multiple workers return free‑form text, letting a writer arbitrarily resolve conflicts is unsafe. Instead, each branch should produce a structured evidence record containing claim, source, observation time, data version, confidence, and artifact ID. The merge node first deduplicates by artifact ID, then checks for claim, time, or source conflicts. Unresolvable conflicts should be marked as conflict and handed off for manual verification rather than automatic LLM voting.

Priorities must be tied to claim type, source version, and timeliness—not to the agent’s name. For example, a three‑day‑old customer‑service summary should not automatically outweigh a fresh transaction status unless the claim type dictates otherwise.

Ensuring Idempotence and Handling Late Results

Each dispatch should carry a task ID, branch ID, and input version. Workers must validate the version on return, and duplicate results should be filtered using an idempotency key. If a user cancels the overall task, any late write operations must be prevented from reverting the cancelled state.

Completion is declared only after all required artifacts are present, schema validation passes, conflicts are resolved or explicitly retained, and side‑effects have verifiable execution evidence. Only then should a Supervisor announce the completed state.

Key Design Questions for Multi‑Agent Systems

Who can run in parallel, which branches are required, how to cancel after failure, how to merge results, and how to block duplicates or late arrivals. Answering these with code and explicit state definitions keeps the Supervisor a controlled scheduler rather than an opaque, hard‑to‑debug component.