Open arthur-tacca opened 5 months ago
As my second comment at the linked post says, Trio changed to the current behaviour in version 0.11.0 (2019-02-09).
I tried fixing this by raising a new CancelledError
from CancelScope.__exit__()
, but that interacted poorly with task groups, as they're not prepared to handle exceptions falling out of that method (timeouts in taskgroup.cancel_scope
are not a thing).
Things to check first
[X] I have searched the existing issues and didn't find my bug already reported there
[X] I have checked that my bug is still present in the latest release
AnyIO version
4.3.0
Python version
3.10.13; 3.12.1
What happened?
Run a cancel scope within another cancel scope. Cancel the inner one then
await
something so that a cancellation exception is raised, but during handling also cancel the outer one (but do not call any more unshielded async functions before the end of the inner block). With the asyncio backend, the inner block will swallow the cancellation exception, allowing the outer block to continue running (until the next unshieldedawait
in it), while the Trio backend will propagate the exception right out to the end of the outer blockBy the way, the Trio docs give the impression that it is meant to work the same way as the asyncio backend does. (See discussion on Trio Discourse: Do
Cancelled
exceptions “know” which block they belong to?)How can we reproduce the bug?
Output with Trio backend:
Output with asyncio backend: