Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

Nested TaskGroup can silently swallow cancellation request from parent TaskGroup #116720

Closed
Labels
@arthur-tacca

Description

@arthur-tacca

Bug report

Bug description:

In the following code snippet, I start anasyncio.TaskGroup calledouter_tg then start another one within it calledinner_tg. The inner task group is wrapped in anexcept* block to catch a specific type of exception. A background task in each task group raises a different exception at roughly the same time, so the inner one ends up (correctly) raising the inner exception in anExceptionGroup, which is caught and discarded by theexcept* block. However, this means that there is now no longer any exception bubbling up through the call stack, and the main body of the outer task group just continues on, even allowing waiting on more routines (but not creating more tasks in the outer group, as it is still shutting down).

importasyncioclassExceptionOuter(Exception):passclassExceptionInner(Exception):passasyncdefraise_after(t,e):awaitasyncio.sleep(t)print(f"Raising{e}")raisee()asyncdefmy_main():try:asyncwithasyncio.TaskGroup()asouter_tg:try:asyncwithasyncio.TaskGroup()asinner_tg:inner_tg.create_task(raise_after(1,ExceptionInner))outer_tg.create_task(raise_after(1,ExceptionOuter))            except*ExceptionInner:print("Got inner exception")print("should not get here")awaitasyncio.sleep(0.2)print("waited")# outer_tg.create_task(asyncio.sleep(0.2)) # raises RuntimeError("TaskGroup shutting down")    except*ExceptionOuter:print("Got outer exception")print("Done")asyncio.run(my_main())

Expected vs observed behaviour:

Observed behaviour:

Raising <class '__main__.ExceptionInner'>Raising <class '__main__.ExceptionOuter'>Got inner exceptionshould not get herewaitedGot outer exceptionDone

Expected behaviour: the rest of the main body of the outer task group is skipped, so we just see:

Raising <class '__main__.ExceptionInner'>Raising <class '__main__.ExceptionOuter'>Got inner exceptionGot outer exceptionDone

Variations:

Making either of these changes (or both) still gives the same issue:

  • Add a third line within the inner task groupawait asyncio.sleep(10). This means that the main body of the inner task group finishes withasyncio.CancelledError rather than just finishing before any exceptions are raised by tasks.

  • Replaceinner_tg.create_task(raise_after(1, ExceptionInner)) withinner_tg.create_task(raise_in_cancel()), where:

asyncdefraise_in_cancel():try:awaitasyncio.sleep(10)exceptasyncio.CancelledError:raiseExceptionInner()

It's fair to dismiss this second case because it violates the rule about not suppressingCancelledError).

Root cause:

I think the problem is thatTaskGroup.__aexit__() never includesCancelledError in the ExceptionGroup it raises if there are any other types of exception, even if a parent task group is shutting down. That appears to be due to this code inTaskGroup.__aexit__() (specifically theand not self._errors part, becauseself._errors is the list of all non-cancellation exceptions):

# Propagate CancelledError if there is one, except if there# are other errors -- those have priority.ifpropagate_cancellation_errorandnotself._errors:raisepropagate_cancellation_error

I'm not sure of the right solution. Here are a couple of possibilities that come to mind, but I'm not sure if either would work or what the wider implications would be.

  • Perhaps, after all child tasks are completed,TaskGroup.__aexit__(), after needs to walk up the stack of parent task groups and see if any of those are shutting down, and if so include aCancelledError in theExceptionGroup.
  • Maybe CancelledError needs to include some metadata about what task group caused it to be raised and then it's only suppressed by the task group it's associated with (that's what Trio and AnyIO do I believe).

CPython versions tested on:

3.11, 3.12

Operating systems tested on:

Windows

Linked PRs

Metadata

Metadata

Assignees

No one assigned

    Labels

    Projects

    Status

    Done

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions


      [8]ページ先頭

      ©2009-2025 Movatter.jp