Tin Tvrtković <tinches...@gmail.com> added the comment:
Ok, first the happy path. We have a task running this:
async def a():
with move_on_after(5):
await a_long_op()
await something_else()
`move_on_after` has scheduled a callback to run that calls
`parent_task.cancel(msg=1)` 5 seconds after it was executed.
So now 5 seconds pass, the callback cancels the task, and `move_on_after`
catches the CancelledError, sees the msg == 1, and swallows it.
`something_else()` now runs. All good.
Sad path. Same scenario, except the event loop is kinda busy since we're
running in production. Turns out this task was spawned by a web server, and
there's a 5 second timeout (or the client disconnected, or something else). So
now we have 2 callbacks that want to cancel this task: the one from
`move_on_after` and the one from the web server.
The one from the web server is more important, since it's a higher level
cancellation. But the callback from `move_on_after` runs first, and marks the
task for cancellation, and sets the message to 1. Then, before the task gets to
run, the webserver also cancels the task. But that does nothing:
https://github.com/python/cpython/blob/6f1efd19a70839d480e4b1fcd9fecd3a8725824b/Lib/asyncio/tasks.py#L206.
So now the task actually gets to run, `move_on_after` swallows the
CancelledError, and something_else() gets to run. But ideally, it shouldn't.
----------
_______________________________________
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue46771>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
