[asyncio] cancelling task cancels awaited task instead

[Tinche]

The issue boils down to this line:

cpython/Lib/asyncio/tasks.py

Line 215 in 6bc65c3

if self._fut_waiter.cancel(msg=msg):

First off the bat, I realize this may be impossible to change due to backwards comp. Still, let's discuss.

Task A awaits task B. Someone cancels task A. Task B gets cancelled instead.

This probably makes sense in some contexts, for example if task A is the logical owner/parent of task B.
But in my case, task B was created in a long-lived taskgroup. Its lifecycle is independent of task A. They are now coupled by this invisible link created by the await.

I wonder if we could make this cancellation forwarding be skipped in some cases, like if the awaitee was created through a task group (since that mitigates the danger of leaking tasks).

[zware]

ISTM this would be a case for await asyncio.shield(B) rather than await B.

[Tinche]

Yeah, that would be the mitigation here. However, and correct me if I'm wrong (I might be, it's been a while since I dug through the code):

• Getting cancelled while waiting to pull from a queue doesn't shut the queue down
• Getting cancelled while trying to read from a socket (or selector or whatever) doesn't close the socket
• Getting cancelled while waiting on a lock doesn't invalidate the lock

You see where I'm going with this. You need to be mindful of what exactly you're awaiting, and if it happens to be a task, you need to remember to shield the await.

[picnixz]

I'm adding the labels but I would suggest closing this because changing this should rather be discussed on DPO first (https://discuss.python.org/c/ideas/6). You'll also get more participants involved in the discussion.

You need to be mindful of what exactly you're awaiting, and if it happens to be a task, you need to remember to shield the await.

I don't think we should expect the standard library to do all the work or guess what work it should be done. In particular, as you observed, "This probably makes sense in some contexts". Because the standard library can't make wild guesses, this should rather be left to the user.

cc @kumaraditya303

[Tinche]

My thinking was I would get more eyeballs on DPO but maybe actual experts here. Happy to move to DPO though. Can do so in a few days since I'm limited to mobile currently.

I don't think we should expect the standard library to do all the work or guess what work it should be done. In particular, as you observed, "This probably makes sense in some contexts". Because the standard library can't make wild guesses, this should rather be left to the user.

This looks like a footgun to me. Energy spent removing footguns is energy very well spent, especially in systems (like asyncio) that have accumulated a number of them over the years. Ideally we could do better here than an "oh well, the users can aim it away from their foot themselves".

[kumaraditya303]

I am not sure if anything can/should be done for this. As suggested above it can be mitigated with asyncio.shield but other than that it doesn't seem actionable.

[Tinche]

I forgot to close it, doing it now.

As for something actionable, I understand we might be in a cul-de-sac here. Unfortunate.