fix(ios): gate alert activation on a fresh hittable read - #2506
Conversation
A snapshot can surface an alert button before the owning app has made it hittable, and a starved host widens that window. The single, never-repeated activation tapped into that gap, dropping the button press, riding an unchanged alert to ALERT_DEADLINE_EXCEEDED with First actions: 0, and flaking the alert-replacement runner regressions under CI contention. Wait for a fresh exists+isHittable read before the one activation; still activates at most once.
Size Report
Startup median (7 runs, lower is better):
|
|
The new readiness wait can activate an alert after the command deadline at 0d89661. It checks the deadline before the synchronous The earlier iOS smoke failure was an |
The hittable read is a synchronous query that a starved host can complete past the command deadline. It previously handed back true unconditionally, so handleAlert tapped once more after the budget was already gone. Only a read that lands before the deadline buys back the single activation. Route the read through a unit-test-overridable probe and add a regression that completes the probe past the deadline and asserts, via the fixture's own action counter, that no button is activated.
|
Good catch — fixed in 7bbb148. The hittable read is itself a synchronous query, so it now forfeits instead of buying back the single activation: Regression |
|
The post-probe deadline check fixes the late activation at d1e1d1e. The selected regression forces a late successful probe and verifies the deadline error with zero original or replacement actions; current-head checks pass, including iOS and macOS, and there are no conflicts. Ready for human review and merge. Please also refresh the description’s old validation SHA, file count and test count to match this revision. |
thymikee
added
the
ready-for-human
|
1 participant
Summary
Hardens the single, never-repeated alert activation. A snapshot can expose an alert button a beat before the owning app has made it hittable, and a starved CI host widens that window. The one activation tapped into that gap, so the press was dropped, the presentation never changed, and the whole budget rode an unchanged alert to
ALERT_DEADLINE_EXCEEDEDwithFirst actions: 0— the signature of the flakyalert-replacement runner regressions onmain.Now
handleAlertwaits for a freshexists && isHittableread before the activation, still activating at most once (preserves #2326's no-retry guarantee).One file, runner-test target only. No production, CLI, or cross-platform surface change.
Validation
Commit
0d89661f18.0 failures; the threealert-replacement regressions pass.TEST BUILD SUCCEEDED(shared alert source, guards the fix(ios): confirm alerts without repeating activation #2326 macOS-compile pitfall).pnpm check:affected --run:xctest-selectionandpackaged-runner-swiftpass; Swift builds + device lanes are GitHub-authoritative (running on this PR).Residual risk: the flake is CI-contention-specific (~10% of recent
mainruns, ~13x slowdown) and did not reproduce on warm machines, so the green device lanes confirm no regression rather than a reproduced-before/after. Thewebview-remote-contentRUNNER_BUSYfailures were the separate dominant cause and are addressed by the already-merged #2493.