8000 bpo-37658: Actually return result in race condition by Dreamsorcerer · Pull Request #29202 · python/cpython · GitHub
[go: up one dir, main page]

Skip to content

bpo-37658: Actually return result in race condition #29202

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

Merged
merged 6 commits into from
Nov 29, 2021
Merged
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Prev Previous commit
Next Next commit
Avoid timing issues with test.
  • Loading branch information
Dreamsorcerer authored Oct 25, 2021
commit 169294e95f8f373317d048bcd89ab3516352314f
5 changes: 3 additions & 2 deletions Lib/test/test_asyncio/test_tasks.py
Original file line number Diff line number Diff line change
Expand Up @@ -1010,11 +1010,12 @@ def gen():

def test_wait_for_cancellation_race_condition(self):
async def inner():
await asyncio.wait_for(asyncio.sleep(1), timeout=2)
with contextlib.suppress(asyncio.CancelledError):
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Initially I just emulated the race condition in the bug report, but because it's a race condition, it seems that the test occasionally failed due to actually hitting the timeout.

Instead, I've just suppressed the cancellation, which makes the behaviour 100% reproducible.

Choose a reason for hiding this comment

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

This is not an equivalent test. As I understand, the whole point of that test was to inject the cancellation at the exact point to cause the race on the return to ‘await waiter’ once fut is done. The new test is not checking this race at all but instead checking that a cancellation ignoring task can skip the timeout.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

It's not an equivalent test, because the previous test is completely wrong. It does not emulate a race condition, and it does not reproduce the issue in the bug report.

I wrote a test which actually reproduces the race condition as given in the bug report, and the issue was not fixed. As mentioned above, I had to use this suppress cancellation trick to make the test reproducible (it will still run things in the same order as the race condition), the original test worked correctly everytime I ran it, but failed in one of the CI runs, and we can't have flaky tests.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

You can see the old version which was timing dependent in the commit history:
169294e

await asyncio.sleep(1)
return 1

async def main():
result = await asyncio.wait_for(inner(), timeout=1)
result = await asyncio.wait_for(inner(), timeout=.01)
assert result == 1

asyncio.run(main())
Expand Down
0