-
-
Notifications
You must be signed in to change notification settings - Fork 32k
bpo-37658: Fix asyncio.wait_for() to respect waited task status #21894
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
bpo-37658: Fix asyncio.wait_for() to respect waited task status #21894
Conversation
Currently, if `asyncio.wait_for()` itself is cancelled it will always raise `CancelledError` regardless if the underlying task is still running. This is similar to a race with the timeout, which is handled already.
`asyncio.wait_for()` currently has a bug where it raises a `CancelledError` even when the wrapped awaitable has completed. The upstream fix is in python/cpython#21894. This adds a workaround until the aforementioned PR is merged, backported and released. Fixes: #467 Fixes: #547 Related: #468 Supersedes: #548
`asyncio.wait_for()` currently has a bug where it raises a `CancelledError` even when the wrapped awaitable has completed. The upstream fix is in python/cpython#21894. This adds a workaround until the aforementioned PR is merged, backported and released. Co-authored-by: Adam Liddell <[email protected]> Fixes: #467 Fixes: #547 Related: #468 Supersedes: #548
Closed/reopen the pr to hopefully fix unreported Travis status blocking the merge. |
@1st1: Please replace |
…onGH-21894) Currently, if `asyncio.wait_for()` itself is cancelled it will always raise `CancelledError` regardless if the underlying task is still running. This is similar to a race with the timeout, which is handled already. (cherry picked from commit a2118a1) Co-authored-by: Elvis Pranskevichus <[email protected]>
GH-21964 is a backport of this pull request to the 3.9 branch. |
GH-21965 is a backport of this pull request to the 3.8 branch. |
Sorry, @elprans and @1st1, I could not cleanly backport this to |
…onGH-21894) Currently, if `asyncio.wait_for()` itself is cancelled it will always raise `CancelledError` regardless if the underlying task is still running. This is similar to a race with the timeout, which is handled already. (cherry picked from commit a2118a1) Co-authored-by: Elvis Pranskevichus <[email protected]>
…1894) (GH-21964) Currently, if `asyncio.wait_for()` itself is cancelled it will always raise `CancelledError` regardless if the underlying task is still running. This is similar to a race with the timeout, which is handled already. (cherry picked from commit a2118a1) Co-authored-by: Elvis Pranskevichus <[email protected]>
…1894) (#21965) Currently, if `asyncio.wait_for()` itself is cancelled it will always raise `CancelledError` regardless if the underlying task is still running. This is similar to a race with the timeout, which is handled already. (cherry picked from commit a2118a1) Co-authored-by: Elvis Pranskevichus <[email protected]>
…pythonGH-21894) Currently, if `asyncio.wait_for()` itself is cancelled it will always raise `CancelledError` regardless if the underlying task is still running. This is similar to a race with the timeout, which is handled already.. (cherry picked from commit a2118a1) Co-authored-by: Elvis Pranskevichus <[email protected]>
GH-21969 is a backport of this pull request to the 3.7 branch. |
`asyncio.wait_for()` currently has a bug where it raises a `CancelledError` even when the wrapped awaitable has completed. The upstream fix is in python/cpython#21894. This adds a workaround until the aforementioned PR is merged, backported and released. Co-authored-by: Adam Liddell <[email protected]> Fixes: #467 Fixes: #547 Related: #468 Supersedes: #548
…on#21894) Currently, if `asyncio.wait_for()` itself is cancelled it will always raise `CancelledError` regardless if the underlying task is still running. This is similar to a race with the timeout, which is handled already.
Currently, if
asyncio.wait_for()
itself is cancelled it will alwaysraise
CancelledError
regardless if the underlying task is stillrunning. This is similar to a race with the timeout, which is handled
already.
https://bugs.python.org/issue37658