test(websocket): gate the bind/debug/ignore specs on the response arriving - #444
Merged
Conversation
…iving These three sent a request, slept a fixed 100ms, then asserted on `updates.size`. That is a race, not a wait: under any extra load the response has not arrived yet and the spec fails with "expected 1, got 0" somewhere unrelated to whatever the branch actually changed. `wait_for_updates` already exists for exactly this, with a comment saying so, and the `receives updates` spec already uses it — these three were simply never converted. The helper polls to a 5s deadline and fails loudly on timeout, so a genuine regression still reports as one. Found while merging the Azure consent stack: the `debug` spec failed twice in a row on a branch that only touched the consent controller, while passing on master. Six extra examples were enough to tip it.
1 task
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
1 participant
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.
Three specs in
session_spec.crsent a websocket request, slept a fixed100.milliseconds, then asserted onupdates.size. That's a race rather than a wait — under any extra load the response hasn't arrived and the spec fails withexpected 1, got 0, pointing at websockets when the branch under test had nothing to do with them.wait_for_updatesalready exists in this file for exactly this purpose, with a comment saying so, and thereceives updatesspec already uses it.unbind,debugandignorewere simply never converted.How I found it
Merging the Azure consent stack (#440 → #441 → #442). After rebasing #442 onto master,
websocket API debugfailed twice in a row, while passing on master and on every earlier run of the same code. #442 only touchestenant_consent.crand adds one utility — it cannot affect a websocket subscription. What it does add is six examples with Redis round-trips, and that was enough to push the fixed sleep over.So this is a latent flake that gets exposed by any branch that adds work to the suite, which makes it worth fixing rather than retrying past.
The helper polls to a 5-second deadline and raises on timeout, so a real regression still fails — it just stops failing for the wrong reason.
exec(line ~111) still uses a fixed sleep; it goes throughtest_websocket_exec, which doesn't exposeupdatesto its block. Left alone rather than widened here.🤖 Generated with Claude Code