Tests: make the warm-recorder tests headless-runner-safe - #142
Closed
claude[bot] wants to merge 1 commit into
Closed
Tests: make the warm-recorder tests headless-runner-safe#142claude[bot] wants to merge 1 commit into
claude[bot] wants to merge 1 commit into
Conversation
The three tests driving production warmUp() / scheduleRewarm() reached
prepareWarmRecorder()'s AudioRoute.currentInput() — a CoreAudio HAL query —
on a runner with no input device: 3 expectation failures, plus at least one
blocked CoreAudio call that pinned the cooperative pool and wedged the whole
parallel test process into the job's 30-minute timeout (the suite's
.timeLimit can't fire once the pool is pinned). The re-warm test's unbounded
'while ... { await Task.yield() }' wait made sure nothing shorter than the
job timeout could end it.
Rework those three to drive the same guard logic through the proven
installWarmRecorder(boundTo:) seam and direct state setters: warmUp() and
scheduleRewarm() now appear only on their refusal paths, which return before
the device read. The one remaining wait is deadline-bounded (500 ms) and
cancellation-aware. Add a direct armPreparedRecorderExpiry test to keep line
coverage of the countdown arming that the prepare path used to reach. The
three seam-driven tests that already passed on the runner are unchanged.
Tests only; no production changes. prepareWarmRecorder()'s success path is
now exercised only on hardware, and the header comment says so instead of
claiming CI reachability.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01CNFeP9D8k1HJ1piwyidUv3
3 tasks
Contributor
Author
|
Alex fixed these himself in d378778 — closing. Generated by Claude Code |
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.
Requested by Dylan Fox · Slack thread
Fixes the red CI that #141's tests caused on #133.
What broke on the runner: the three tests in
MicCaptureWarmTests.swiftthat call productionwarmUp()/scheduleRewarm()reachprepareWarmRecorder()'sAudioRoute.currentInput()— a CoreAudio HAL query — on a headless macos-26 runner with no input device. Result in run 31747352994: 3 expectation failures (lines 27, 29, 53), plus at least one CoreAudio call that blocked, pinning the cooperative pool and starving the whole parallel swift-testing process — 72 unrelated in-flight tests never finished and the job hit its 30-minute timeout (the suite's.timeLimitcan't fire once the pool is pinned). The re-warm test's unboundedwhile … { await Task.yield() }wait guaranteed nothing shorter than the job timeout could end it.What this changes (tests only, no production code):
installWarmRecorder(boundTo:)seam and direct state setters; productionwarmUp()andscheduleRewarm()appear only on their refusal paths, which return before the device read.armPreparedRecorderExpirydirectly, recouping countdown-arming coverage the prepare path used to reach.prepareWarmRecorder()'s success path is exercised only on hardware.Coverage impact gets measured by this PR's own check run (last full measure without any warm tests: 87.37% against the 88% gate).
Generated by Claude Code