The point here is forcall_exception_handler() to make an effort to run the exception handler in the correct task context (contextvars.Context), if it is called on behalf of a task.

The easiest way seems to be to retrieve the task context from the task passed into the contextdict that's being passed tocall_exception_handler(). This doesn't always exist, and becauseTask inherits fromFuture, it may be stored under either a"task" key or a"future" key. So try both.

We then need to retrieve thecontextvars.Context from the task, for which I have added aget_context() method to theTask class (analogous toget_name()). It is possible that the task doesn't have this method (e.g. if the loop is using a 3rd party task implementation that doesn't yet support this new method).

Only ifget_context() exists and returns something that has arun() method do we run the exception handler using thatcontextvars.Context.run() method. Otherwise we use the defaultcontextvars.Context.

We only do this for an exception handler set by the user; the default exception handler should not be interested in the context. (This is because I'm lazy, there are two calls to it and I don't want to bother giving those the same treatment -- we can reconsider if you think the logger might also be interested in thecontextvars.Context.)

PS. It's unfortunate thatcall_exception_handler() has a parameter namedcontext that is adict, not acontextvars.Context. But nothing we can do it now (this API probably predatescontextvars).

• Issue:asyncio exception handler called with incorrect context #96704