Skip to content

gh-134471: Fix asyncio.timeout(0) swallowing an unrelated prior cancellation.#134472

Draft
okhaliavka wants to merge 1 commit into
python:mainfrom
okhaliavka:fix-timeout
Draft

gh-134471: Fix asyncio.timeout(0) swallowing an unrelated prior cancellation.#134472
okhaliavka wants to merge 1 commit into
python:mainfrom
okhaliavka:fix-timeout

Conversation

@okhaliavka

@okhaliavka okhaliavka commented May 21, 2025

Copy link
Copy Markdown

@python-cla-bot

Copy link
Copy Markdown

The following commit authors need to sign the Contributor License Agreement:

CLA signed

@bedevere-app

bedevere-app Bot commented May 21, 2025

Copy link
Copy Markdown

Most changes to Python require a NEWS entry. Add one using the blurb_it web app or the blurb command-line tool.

If this change has little impact on Python users, wait for a maintainer to apply the skip news label instead.

Comment on lines +307 to +311
async def test_timeout_immediately_after_cancellation(self):
asyncio.current_task().cancel()
with self.assertRaises(asyncio.CancelledError):
async with asyncio.timeout(0.0):
await asyncio.sleep(1)

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this added test fails on all python versions and the proposed fix makes it pass without breaking any other tests

Comment thread Lib/asyncio/timeouts.py
self._state = _State.ENTERED
self._task = task
self._cancelling = self._task.cancelling()
self._must_cancel = self._task._must_cancel

@okhaliavka okhaliavka Sep 22, 2025

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i feel uneasy messing around with this internal _must_cancel but i didn't find any other way to fix this. changing the cancellation counting logic breaks timeout usage while handling CancelledError, where it should indeed disregard the previous cancellation (the one it's handling). I couldn't get both cases to work by only relying on counting (cancelling).

so i needed something more "surgical" to be able to tell whether we're currently handling CancelledError or we're just in an already cancelled task that didn't get thrown a CancelledError yet

@github-actions

Copy link
Copy Markdown

This PR is stale because it has been open for 30 days with no activity.

@github-actions github-actions Bot added the stale Stale PR or inactive for long period of time. label Apr 25, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

stale Stale PR or inactive for long period of time.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants