Summary
PTTInputDeviceProbeTests.testMainRunLoopKeepsPumpingWhileTheHALIsWedged is flaky in Desktop Swift CI. The production change from #10695 is not implicated by the failures: the test's fixed 300 ms window asserts more than 10 timer ticks and more than 10 snapshot reads, turning a liveness requirement into a runner-throughput requirement.
Evidence
Two independent failures after #10695 landed:
In both runs, every sibling PTTInputDeviceProbeTests case passed. Other current-main runs pass, confirming the result depends on macOS runner contention.
Root cause
The acceptance criterion is binary: while the injected HAL probe is blocked off-main, the main run loop and currentSnapshot path must continue making progress. Requiring an arbitrary 11+ iterations in 300 ms measures host scheduling throughput instead. Under suite isolation and a loaded arm64 runner, RunLoop.main.run(mode:before:) may service only a few iterations even though neither the main actor nor snapshot read is blocked.
Proposed fix
Keep the HAL semaphore wedged and assert deterministic liveness/progress, not a fixed iteration rate. The test should still fail if the routing read moves back onto the main actor or waits for the HAL, while accepting any positive main-loop and turn-start progress under contention.
No production code change is needed.
Summary
PTTInputDeviceProbeTests.testMainRunLoopKeepsPumpingWhileTheHALIsWedgedis flaky in Desktop Swift CI. The production change from #10695 is not implicated by the failures: the test's fixed 300 ms window asserts more than 10 timer ticks and more than 10 snapshot reads, turning a liveness requirement into a runner-throughput requirement.Evidence
Two independent failures after #10695 landed:
main, run 30276084659:reads == 10, failingXCTAssertGreaterThan(reads, 10)ticker.count == 5andreads == 4In both runs, every sibling
PTTInputDeviceProbeTestscase passed. Other current-main runs pass, confirming the result depends on macOS runner contention.Root cause
The acceptance criterion is binary: while the injected HAL probe is blocked off-main, the main run loop and
currentSnapshotpath must continue making progress. Requiring an arbitrary 11+ iterations in 300 ms measures host scheduling throughput instead. Under suite isolation and a loaded arm64 runner,RunLoop.main.run(mode:before:)may service only a few iterations even though neither the main actor nor snapshot read is blocked.Proposed fix
Keep the HAL semaphore wedged and assert deterministic liveness/progress, not a fixed iteration rate. The test should still fail if the routing read moves back onto the main actor or waits for the HAL, while accepting any positive main-loop and turn-start progress under contention.
No production code change is needed.