Repository navigation
The slow-Drive test no longer fails when a loaded runner slows the Drive's close (#950) - #955
Merged
Merged
Conversation
…ive's close (#950) slowDrive's recorder gave Stop a 300 ms no-progress window, so a Drive writer that paused that long at the close was given up: Repair skipped it and the stand-in stayed on the Device, the three expectations that failed in CI. The test's recorder now takes a stop window (default unchanged), and slowDrive sets 30 s, which still bounds a hang. The Drive stem closes 600 ms late in the test, which reproduced the failure before the change. Assisted-by: Claude Code:claude-sonnet-5-5
Skeyelab
enabled auto-merge (squash)
October 24, 2026 02:51
2 tasks
Codecov Report✅ All modified and coverable lines are covered by tests. 📢 Thoughts on this report? Let us know! |
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.
Fixes #950.
What
slowDrivefailed once in CI (run 39868816619, 34.5 s) on three expectations: the Drive wasn't.repaired, its samples didn't match, and the Device Take folder still existed. That last one means the stand-in did start (the issue text guessed it never did; I'll correct it there). What fits all three is that Stop gave the Drive up:TakeSession.finishwaits on the writers with a no-progress window (writerStopTimeout), and this test's recorder hard-coded 300 ms. A Drive writer that makes no progress for 300 ms at its close is abandoned. Repair skips an abandoned Drive, and the stand-in stays on the Device. On a starved runner a 300 ms pause is easy to hit.The test's recorder helper now takes a
stopTimeout(default 300 ms, so every other test is unchanged).slowDrivesets 30 s. That still bounds a hang: a writer with no progress for 30 s is given up, and a finished writer returns at once.Red first
SlowStemgets afinalizeDelay, andslowDriveuses 600 ms. With the 300 ms window it fails on the same three expectations as CI (3 issues). With the 30 s window it passes. The whole DriveOnlyTakeTests suite passed three runs in a row (90 tests each).VERIFY_QUICK=1 ./scripts/verify.shpasses.What this does and doesn't prove
The red run reproduces a pause of at least the window in the Drive writer, which matches CI's failure. It is not a measured cause: the CI log has no direct proof, and the failure didn't reproduce idle (25/25), under load with the full target (3/3), or with 24 hogs on this test alone (60/60). If #950 comes back with
.repairedbut a sample mismatch, look at the loop that feeds 5 s of audio in about 0.5 s (10 times real time, though the comment says audio never arrives faster than real time).Tests only; no code under Sources changes.