Problem
When a wait times out while the XCTest runner is still starting, the cancellation stops that runner. A retry with the same timeout then pays the whole runner start again, so on a slow host a short-timeout wait can never succeed. In one run on 2026-09-24 (iOS 26.2 Simulator), the runner took 31 s to stop after a 4 s wait timeout.
Found while working on #2343 (PR #2893). #2893 now reports this case as wait_readiness_exhausted with readinessPhase: runner-start. It does not change the lifecycle.
Required behavior
Decide and implement one of these:
- a runner start that a caller's deadline cancelled keeps going in the background, so the next request joins it;
- the start is budgeted separately from the observation deadline.
Either way, cancelling a start stops it promptly and not tens of seconds later. The retry after a readiness timeout must not pay the full start again.
Evidence to reproduce
open the fixture app, kill the runner, terminate the app, then wait text … 4000 repeatedly. Watch runner start and stop times in the daemon log.
Problem
When a
waittimes out while the XCTest runner is still starting, the cancellation stops that runner. A retry with the same timeout then pays the whole runner start again, so on a slow host a short-timeout wait can never succeed. In one run on 2026-09-24 (iOS 26.2 Simulator), the runner took 31 s to stop after a 4 swaittimeout.Found while working on #2343 (PR #2893). #2893 now reports this case as
wait_readiness_exhaustedwithreadinessPhase: runner-start. It does not change the lifecycle.Required behavior
Decide and implement one of these:
Either way, cancelling a start stops it promptly and not tens of seconds later. The retry after a readiness timeout must not pay the full start again.
Evidence to reproduce
openthe fixture app, kill the runner, terminate the app, thenwait text … 4000repeatedly. Watch runner start and stop times in the daemon log.