Diagnose recurring multi-minute Settings replay click in iOS Smoke

[thymikee]

Purpose

Reduce a recurring multi-minute delay in the iOS Smoke Settings replay and determine whether its successful click General response reflects a completed interaction.

Evidence

Three independent exact-head PR runs on 2026-09-24 show the same pattern in 01-settings.ad: the first attempt reports step 3 click General as successful after 143.840 s, 191.076 s, or 165.128 s; step 4 then times out after 5 s waiting for About, Software Update, or the expected Settings text. The retry succeeds in 30.5 s, 23.6 s, or 14.8 s respectively.

• #2936 iOS job: click 143.840 s, replay 234.3 s including retry.
• #2937 iOS job: click 191.076 s, replay 242.8 s including retry.
• #2938 iOS job: click 165.128 s, replay 216.1 s including retry.

The recorded replay timing establishes the delay and failed wait; it does not establish which internal click phase consumed the time or whether the tap landed. The #2936 failed wait request log includes a simulator-target-discovery-pending bridge fallback, but successful click requests did not retain equivalent phase diagnostics.

Required behavior

• Attribute the click time to target resolution, snapshot/bridge acquisition, XCTest transport, tap synthesis, and post-action work using existing request/session diagnostics or narrowly scoped new timings.
• Determine from a live failing attempt whether General was actually activated before reporting click success; repair the owning path if success can be reported without the action, or bound an optional pre-action probe beneath the operation it precedes.
• Preserve the retry as failure containment while diagnosing; do not treat the retry as proof of click correctness.

Completion

• A live iOS run captures enough phase evidence to explain the 143–191 s first-attempt clicks and the subsequent failed wait.
• A focused fix or an evidence-backed infrastructure disposition removes the repeated multi-minute cost without hiding a failed action. Compare exact-head iOS runner time and replay step timing against the linked runs.

Depends on no current PR; this is separate from #2936's depth-frontier diagnostic.

[thymikee]

The first-click delay is predominantly runner startup, not tap synthesis. In the linked #2936 job, the runner was preflighted (97.0 s), then the workflow ran pnpm clean:daemon, releasing it. The first Settings click took 143.8 s; its runner log shows an interrupted initial launch, a full build-for-testing, another interrupted launch, then a ready runner. Once ready, snapshot and tap completed in under 3 s; the tap was synthesized at (201, 406) and reported success, but the next wait still timed out. That does not prove navigation occurred.

#2949 keeps the prepared runner alive through the replay. A local dedicated simulator passed the replay in 10.0 s with the same daemon (1.3 s click), versus 12.0 s after cleanup (1.4 s click); the local cache was warm. I am waiting for exact-head CI to measure the cold-run benefit. This issue remains open for the failed post-tap destination check and any remaining startup delay.

[thymikee]

Exact-head #2949 iOS job passed and proves the prepared runner was reused: one preflight xcodebuild launch, runner PID 30721 serving both preflight and Settings commands, and no rebuild before replay. The Settings step fell from 4m50s to 1m28s; first click fell from 143.840 s to 18.189 s.

The remaining first-attempt failure is real. open reported postOpenObservation: unobservable; first click spent 13.1 s in a runner snapshot after a 4 s system-modal probe timeout and private-AX fallback, then the tap command completed in 1.1 s. The subsequent wait failed after 9.0 s; attempt 2 passed with a 4.7 s click. Runner reuse removes the multi-minute restart/build penalty but does not establish that the first tap navigated. Keep this issue open for the residual snapshot and post-tap behavior.

[thymikee]

Follow-up on the residual after #2949: the failed attempt does not prove a missed tap. The first runner snapshot took 13.09 s (4 s system-modal probe timeout, drain, then private-AX fallback); the tap took 1.07 s. The next wait received no readable capture before its deadline: its bridge acquisition was canceled, and the runner fallback snapshot completed after the wait. The failed attempt tapped (201,319) and the passing retry (201,406), but the older #2936 failure tapped (201,406) too, so coordinate difference is not causal proof.

A separate local replay passed; its 19.5 s click was cold runner startup and did not reproduce this wait failure. The next diagnostic run should enable global --debug for the Settings test and retain an on-failure screen image or video plus the selected-node rectangle and capture backend. That would tell us whether navigation missed or the wait simply lacked a readable capture. No interaction fix is justified from the current artifacts.