slowDrive flaked once in CI: the Device never stood in (run 39868816619, 34.5 s) #950

Summary

The test "A Drive too slow to keep up drops audio but isn't given up: the Device stands in from the drop, and Repair fills the Drive" (slowDrive, Packages/ShowRecorderKit/Tests/RecordingTests/DriveOnlyTakeTests.swift) failed once in CI on a pull request that doesn't touch that path. It has not failed since in any run we could make.

Why it matters

A red package-tests job blocks a PR for a reason that has nothing to do with the PR. If it comes back, we need what this run showed so we don't start from zero.

Done when

• The cause is found, or it fails again and the new log is added here.
• If the cause is a test wait, the wait is bounded (red first), as in Two #874 tests that wait out a lost query use a longer, named timeout #939.

Details

Failure: CI run 39868816619, job 120137816462 ("App (package tests)", Debug) on #930. Release package tests passed in the same run. The test took 34.5 s; it takes about 1 s on a quiet Mac, so that runner was heavily loaded. Three expectations failed at DriveOnlyTakeTests.swift:636-638: copies[.drive] was .complete, not .repaired; the Drive samples did not match; the Device Take folder still existed. That reads as the Device never standing in. The stand-in only starts when checkDestinations() sees the Drive overflowed, failed or stalled (standInIfDriveLost).

Not reproduced:

• 25 of 25 passes idle on the Reopening a Stem refuses one whose audio starts later than ours (#881) #930 branch, and 25 of 25 on main.
• 3 of 3 passes on the branch and 3 of 3 on main under load: the full RecordingTests target, LIBDISPATCH_COOPERATIVE_POOL_STRICT=1, 12 yes hogs, SHOWRECORDER_BUILD_SLOTS=1 (the pattern in Timing-dependent waits in package tests fail under load #646 and The screen freezes at Stop on a slow Drive #652).

Not #930: #930 changes StemWriter.reopen and the order in ChannelRenamer. Repair reopens Stems our own writer made, and the new guard accepts those.

Which wait: unknown. The test's waitUntil { recorder.droppedFrameCount > 0 } and the checkDestinations() call right after it are the first places to look: the test delivers 5 s of audio in about 0.5 s, so a loaded runner may reorder the drop and the check.

Not built. Filed so we see it if it comes back.