As I've left a reply in the discourse thread, I'm concerned about potential memory leaks when a taskgroup with defer_errors=True is long-lived (e.g., throughout the entire lifecycle of the event loop, or the "server" usage scenario) because the current implementation stores all unhandled exceptions in self._errors for an indefinite length of time.

I'd like to have some discussion on the design of handling the exceptions for long-lived cases.

Ideas:

1. Rename defer_errors=True to ignore_errors=True and let it drop all unhandled errors immediately to keep running.
   • Cons: yet another silent swallowing of exceptions...
2. Replace defer_errors=True with delegate_errors=handler_func, where handler_func shares the compatible interface with loop.call_exception_handler(). If it is None (default), behave like the original taskgroup.
   • Cons: what whould be the difference to task.add_done_callback() by the caller?
3. Split the behavior of "store-and-raising up exceptions as exception group" and "skipping cancellation of child tasks" as two separate options:
   • asyncio.TaskGroup(raise_errors: bool, cancel_together: bool)
     or asyncio.TaskGroup(raise_errors: bool, run_to_completion: bool)
     • raise_errors=True: stores unhandled exceptions and raises up as exception group upon exit, otherwise silently drop them.
     • cancel_together=False / run_to_completion=True: does not cancel other children when it sees the first unhandled exception.
   • Cons: too complicated

The current aiotools.Supervisor works like the first one. I'm using add_done_callback() to catch unhandled exceptions to implement safe_as_completed() and alikes.

This is why I wanted to have a separate API to avoid confusion because the semantic is different at the first place (even though it may be technically feasible to implement as an option to TaskGroup):

• TaskGroup: all child tasks share the same destiny (always cancelled together, exception group)
  • May have strong references to the child tasks
  • Intended to be short-lived
• Supervisor: each child task has its own destiny (run to completion, individual exception handling)
  • Should have weak references to the child tasks
  • Intended to be long-lived
  • Child tasks are cancelled together only when explicitly requested via shutdown()

In fact, Supervisor (or TaskScope) is more versatile: it can be used as an underlying lower-level primitive to write higher-level coroutine utilities—that's why I've suggested a naming like "TaskScope". Even TaskGroup could be written from TaskScope with custom task callbacks or a custom exception handler that immediately calls shutdown() upon the first exception and store-and-raise up exceptions as an exception group. #105011 demonstrates this.