Things to check first
Feature description
It would in fact be helpful, if the error message of a CancelledError would contain some hint on the source location of the originating cancel scope. Because of wrapping, a stack trace would be even better. In case there are concerns regarding the overhead on every cancel scope creation, perhaps it could be opt-in using some ContextVar (to avoid global variables). That opt-in mechanism could also allow setting a stack-trace depth limit.
Use case
I have a somewhat complicated code-base with multiple layers of cancel scopes, some explicit, some hidden by a task group. In certain cases, my code receives a CancelledError that it shouldn't (from an application logic perspective), and I need to chase down what triggered that cancellation. While the exception message (at least on asyncio) does hint at which cancel scope "owns" this exception, it's still quite difficult for me to identify where that cancel scope originates from.
Things to check first
Feature description
It would in fact be helpful, if the error message of a
CancelledErrorwould contain some hint on the source location of the originating cancel scope. Because of wrapping, a stack trace would be even better. In case there are concerns regarding the overhead on every cancel scope creation, perhaps it could be opt-in using someContextVar(to avoid global variables). That opt-in mechanism could also allow setting a stack-trace depth limit.Use case
I have a somewhat complicated code-base with multiple layers of cancel scopes, some explicit, some hidden by a task group. In certain cases, my code receives a
CancelledErrorthat it shouldn't (from an application logic perspective), and I need to chase down what triggered that cancellation. While the exception message (at least on asyncio) does hint at which cancel scope "owns" this exception, it's still quite difficult for me to identify where that cancel scope originates from.