Let the notify test observe the seam instead of the clock - #604
Merged
Conversation
Sibling of the drain-deadline fix: a wall-clock assumption that holds
serially and not under `-n 4`. This one had two, and the first was
silently unsound.
await asyncio.sleep(0.05) # hope add_listener has finished
...
assert elapsed < 1.0 # a clock standing in for "the notify woke it"
If the sleep is too short the NOTIFY is delivered to nobody and dropped,
so `wait()` falls through to its own timeout and the test fails on
exactly the condition it exists to rule out. The old comment named that
race and then slept anyway.
Both replaced with signals the code already exposes. Readiness now waits
on the `_listening` flag `_ensure_listening` sets, so the NOTIFY cannot
be sent into the void. The conclusion reads `_event`, which `wait()`
clears before waiting and `_on_notify` sets: set means the notify woke
it, clear means the timeout did. That is the claim the test's name makes,
asserted rather than inferred from elapsed time.
The remaining bounds are hang guards, not timing assertions. At 20s they
are far above any plausible contention delay and far below the 60s
per-test cap, so a genuine hang still fails as a hang.
Verified where it broke: two full runs under `-n 4`, 47,331 passed each.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Sibling of #603: a wall-clock assumption that holds serially and not under
-n 4. This one had two, and the first was silently unsound.The problem
If the 50ms sleep is too short, the
NOTIFYis delivered to nobody and dropped.wait()then falls through to its own timeout, and the test fails on exactly the condition it exists to rule out. The old comment named that race and slept anyway.The
elapsed < 1.0assertion is the same species: a timing proxy for a semantic claim.The fix
Both replaced with signals the code already exposes:
sleep(0.05)and hope_listeningflag_ensure_listeningsetsassert elapsed < 1.0assert wakeup._event.is_set()wait()clears_eventbefore waiting;_on_notifysets it. Set means the notify woke it, clear means the timeout did — which is the claim the test's name makes, now asserted rather than inferred.The remaining bounds are hang guards, not timing assertions. At 20s they sit far above any plausible contention delay and far below the 60s per-test cap, so a genuine hang still fails as a hang.
Verification
Two full runs under
-n 4— the configuration where it failed: 47,331 passed each. Also 3/3 serial and 3/3 under targeted contention.🤖 Generated with Claude Code