Repository navigation
Fix two macOS flakes: sound level and stalled-receiver tests - #124
Merged
Merged
Conversation
Member
Author
|
Stability: the macOS jobs (check and devices) of the final head were rerun 3 more times after the first green run: 4 of 4 green for both. (Devices once failed before on tunnel.rs:451 and play.rs, both unrelated and green on rerun.) |
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.
Two flaky tests that fail on the macOS runner and turn unrelated PRs red (#110-#112).
Causes
the_streamer_s_sound_is_played_by_the_viewer(sound.rs): asserted that the single highest played sample is below 0.35 (tone peak 0.25). Opus overshoots on the first packets and where a late packet is concealed or rebuilt, and a slow shared runner stalls the pipeline often enough to hit that (seen: peak 0.388). The test now checks what it is meant to prove, the level of the tone: the 90th percentile of the audible samples (expected 0.247) must lie in 0.2..0.28, and no sample may reach 0.5 (about double gain). Not a retry, and a wrong gain, silence or garbage still fails.a_stalled_receiver_costs_a_bounded_queue_not_a_task_per_packet(traffic.rs): expected at least one expired packet after 10 000 sends and 1.5 s. The sender only stalls once the connection's stream limit/windows are used up, and how many of the 10 000 packets reach the queue depends on how the sender task and the send loop interleave. On a slow runner the sender keeps up with the burst, never stalls, nothing expires (log: tasks 15/15/15,expired == 0). The test now keeps feeding paced batches until a queued packet expires (up to 20 s), checks the task bound all the while, then waits the 1.5 s as before. The thing proven is unchanged: bounded queue, no task per packet, expiry on a stalled receiver.Failure rates before (last 100 runs of
ci, jobcheck (macos-latest), 50 runs)the_streamer_s_sound_is_played_by_the_viewer: 8 (16 %).a_stalled_receiver_...: seen in run 40495192564 (not in the window counted).real_window::the_worker_saves_a_clip_of_a_real_window(share-worker access.rs) 3,share_play.rs:103(a_game_that_goes_away_ends_the_share,hand_over_...) 2,tunnel.rs:4511, clippy errors on unmerged heads 3 (and 1 other not compiled).Stability
macOS job rerun results are listed in a comment below.
Need help on this PR? Tag
@codesmith-botwith what you need.