How do I run independent I/O tasks together and handle a failing task without leaving other work running unnoticed?

The runnable example below is a JavaScript conceptual analogy, executed with Node.js. It uses Promise.all, AbortController and Promise.allSettled to illustrate cooperative cancellation and waiting for cleanup. It is not Python code and its tests do not execute or verify asyncio.gather(), TaskGroup, CancelledError or TimeoutError. The Python recommendations in this article come from the linked Python documentation, not from those JavaScript test results.

Running several independent I/O coroutines at the same time is normal. The bug appears when one of them fails and the calling code treats that exception as if the rest of the batch had somehow stopped with it. In asyncio, that assumption is only true when you make the ownership boundary explicit. A task that has been scheduled still exists until it finishes, fails, or is cancelled and awaited.

The practical failure is not abstract. A search refresh, file transfer, lease renewal, or API fan-out can keep going after the caller has already moved on. That is how stale work leaks through: the code has noticed a failure, but it has not actually brought the other tasks to a terminal state. The reader’s real problem is not merely “how do I start independent tasks?” It is “how do I guarantee that every task in this scope ends before I leave it?”

Python’s own documentation gives the relevant tools. `asyncio.create_task()` starts a coroutine. `TaskGroup` owns a set of tasks and waits for them all. `CancelledError` is the cooperative shutdown signal, and `TimeoutError` is the modern deadline exception to catch when a wait takes too long. The article’s point is that these are not interchangeable helpers; they solve different parts of the same ownership problem.

`asyncio.gather()` is useful when you want to run awaitables concurrently and collect their results in input order. That convenience is exactly why people reach for it first. But the docs are explicit about the failure case: if `return_exceptions` is false, the first raised exception is immediately propagated to the caller, and the other awaitables are not cancelled. They keep running unless you stop them some other way.

That detail matters because it means the wrapper is not a safety boundary by itself. If you launch three workers and one fails quickly, the waiting task sees the failure, but the siblings may still be making progress in the event loop. If your code returns to the caller at that point, you have created the false appearance of completion while background work remains active. The user of the API sees an error, but the system still has live tasks.

The docs also warn about a subtle trap: once `gather()` has already been marked done by propagating an exception, calling `gather.cancel()` later will not cancel the already submitted awaitables. So the fix is not to let the error escape and hope you can clean up afterward. You need either a structured owner such as `TaskGroup` or explicit task references plus a deliberate cancellation-and-await phase before returning.

`TaskGroup` is the structured-concurrency primitive that matches this problem. Its contract is simple and stronger than `gather()`'s: all tasks created in the group are awaited when the context manager exits, and the first non-`CancelledError` failure triggers cancellation of the remaining tasks. That means failure is not just reported; it becomes the signal to close the whole scope.

This is the behavior the reader usually wants when the tasks belong to one operation. If one worker fails while the others are still in flight, the group cancels the siblings, waits for their cleanup, and then raises the resulting exception group if needed. That prevents the caller from continuing with a partly completed batch and makes the end of the operation visible in one place.

The docs also describe how the body of the `async with` block is handled. If a child task fails while the body is still active, the body task itself is cancelled so the block wakes up, but the cancellation is contained inside the context manager instead of leaking out as a stray interruption in the ordinary case. That is why `TaskGroup` is more than syntax sugar: it turns a cluster of tasks into one scope with one exit rule.

A timeout and a cancellation request are not the same event. The asyncio docs deliberately separate them. `asyncio.timeout()` uses cancellation internally, while the deadline exception you normally handle is the built-in `TimeoutError`. That separation matters because a timeout means “stop waiting because the policy limit was reached,” not “this task failed on its own.”

`CancelledError` is also special. It is a subclass of `BaseException`, so ordinary `except Exception` handlers will not catch it. That design exists so cancellation can propagate after cleanup instead of getting swallowed by broad error handling. If a coroutine truly catches `CancelledError`, it should usually perform only cleanup and then re-raise it. The docs warn that suppressing it completely is unusual and requires clearing the cancellation state explicitly with `uncancel()`.

For this article’s problem, that means a failure boundary should not collapse everything into one generic handler. A sibling task may fail, a deadline may expire, or the caller may cancel the whole operation intentionally. The repair is to keep those outcomes distinct so you can stop the rest of the batch without turning every interruption into a misleading application error.

The runnable fixture is a JavaScript analogy for the ownership question, not an asyncio implementation. Its worker function returns a Promise and cooperatively checks an AbortSignal between steps. runNaive starts several workers and returns Promise.all; a rejected promise does not stop the other JavaScript workers. runSafe creates an AbortController, signals cancellation after a failure, waits for all started promises with Promise.allSettled, and then throws the original error. These names belong to this fixture and are not aliases for Python APIs.

Run main.test.mjs with node --test main.test.mjs alongside main.mjs. Three independent cases check this JavaScript implementation: successful workers return results in input order, runNaive leaves sibling progress after a rejection, and runSafe has no further sibling progress after it returns an error. The failure cases use cooperative timer-driven workers. They do not establish a performance bound or a guarantee about an uncooperative dependency, a database commit, or a remote HTTP request. These are assertions to run, not a claim that a Python integration has passed.

For Python, the linked asyncio documentation is the evidence for gather, TaskGroup and cancellation semantics. The Node tests do not exercise Python exception groups, CancelledError propagation, TimeoutError conversion, shield, or TaskGroup cleanup. Before adopting the Python guidance in a service, run a native Python integration check with its actual I/O clients: verify normal completion, one child raising while a sibling is waiting, and an enclosing timeout or cancellation. Observe cleanup and outstanding tasks after the scope exits; do not infer those outcomes from the JavaScript analogy.

The analogy is useful for seeing why observing a failure and waiting for cleanup are separate actions. It does not make AbortController equivalent to TaskGroup. In Python, a coroutine that suppresses CancelledError can interfere with structured cancellation; intentionally shielded work has a different lifetime. Keep those language-specific rules separate from the local Promise behavior and use the native documentation when deciding which operation owns a task.

If the tasks all belong to one logical operation, use `TaskGroup` first. That is the best match when one failure should stop the whole batch and the caller should not see a partially finished scope. The group expresses the ownership directly, so the code does not need to remember to cancel siblings manually after every exception. In the article’s problem, that is usually the right default.

Use `gather()` when you want concurrent results and you do not need sibling cancellation as part of the contract. It is still useful, but it solves a different problem: aggregation, not containment. If you need to preserve input order while still stopping all remaining work on failure, `gather()` alone is not enough. The boundary has to be made explicit elsewhere.

The decision rule is simple. If leaking background work would be harmful, choose the primitive that owns the tasks to completion. If a task may continue independently after the caller has moved on, then that task should not be in the same ownership group in the first place. The article’s example keeps that distinction visible so the reader can apply it to their own I/O batch without confusing concurrency with containment.