You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
assignee=Noneclosed_at=<Date2017-06-11.14:12:51.714>created_at=<Date2017-05-30.02:14:06.380>labels= ['type-bug', '3.7', 'expert-asyncio']
title='"Task exception was never retrieved" reported for a canceled task'updated_at=<Date2017-06-11.15:42:01.895>user='https://bugs.python.org/MiguelGrinberg'
I am seeing a strange issue that occurs when a task that is awaiting an asyncio.wait_for() is cancelled. I created a simple example that I think demonstrates the issue, even though it isn't exactly how it manifests on my application.
When I run the attached script never-retrieved.py I get the following error:
Task exception was never retrieved
future: <Task finished coro=<crash() done, defined at never-retrieved.py:4> exception=ZeroDivisionError('division by zero',)>
Traceback (most recent call last):
File "/usr/lib/python3.5/asyncio/tasks.py", line 239, in _step
result = coro.send(None)
File "never-retrieved.py", line 5, in crash
a =1/0ZeroDivisionError: division by zero
You can see in the script that the future was cancelled, but the cancel() call was made after the task finished in a zero division error. I think the cancel() call should update the internal state of the future so that the "exception was never retrieved" error does not appear.
My application has a more complex setup that I have been unable to reproduce with a simple example. I have a task that is waiting on asyncio.wait_for(fut, timeout), with fut subsequently waiting on a websocket server's receive function. When the websocket client closes the connection, a bunch of cancellations happen, but this future inside the wait_for call crashes before wait_for gets to call cancel() on it. Even though I need to investigate this crash, the fact is that wait_for did cancel this future, but because it already ended in an error the "never retried" error is reported anyway.