Tolerate stalled event synthesis in fixture gate and tab presses (#82) #26

Merged

backmeupplz merged 1 commit from fix/82-synthesis-stall into main

2026-10-13 01:29:42 +00:00

backmeupplz commented

2026-10-13 00:28:51 +00:00

(Migrated from github.com)

Follow-up to #23 for ticket #82 (flaky iOS loading group).

Main's push CI on 535cd45 failed iOS (loading) in LoadingLifecycle.testEmptyOnlyAfterSuccess at FixtureGates.swift:35. On a Release press, XCTest spent 21s in "Check for interrupting elements" and then 30s in "Synthesize event", which failed with "Failed to synthesize event: Timed out while synthesizing event." Because continueAfterFailure is off, that harness error ended the test before the gate's re-press loop could check whether the touch landed.

Change (ios/UITests/FixtureGates.swift only)

A private press(_:) -> Bool helper makes one deliberate 0.1s press. It tolerates only the "Failed to synthesize event" issue: the press runs inside a non-strict XCTExpectFailure with that issue matcher, and continueAfterFailure is temporarily true (restored by defer). It returns false when the press was not synthesized.
gate() uses the helper. It still presses up to 3 times and still requires the value to be released/held.
tab() presses again (at most 3 times) only when the touch was never synthesized and the tab isn't already selected. It still requires isSelected within gateTimeout.

No assertion is loosened, and every other failure during a press still fails the test.

Why continueAfterFailure is toggled: a probe on Xcode 27 showed that, with it false, even an expected (matched) failure stops the test. With it temporarily true, execution continues after a matched failure, and an unmatched failure is still recorded as a test failure.

Follow-up to #23 for ticket #82 (flaky iOS loading group). Main's push CI on 535cd45 failed iOS (loading) in `LoadingLifecycle.testEmptyOnlyAfterSuccess` at `FixtureGates.swift:35`. On a Release press, XCTest spent 21s in "Check for interrupting elements" and then 30s in "Synthesize event", which failed with "Failed to synthesize event: Timed out while synthesizing event." Because `continueAfterFailure` is off, that harness error ended the test before the gate's re-press loop could check whether the touch landed. **Change (`ios/UITests/FixtureGates.swift` only)** - A private `press(_:) -> Bool` helper makes one deliberate 0.1s press. It tolerates only the "Failed to synthesize event" issue: the press runs inside a non-strict `XCTExpectFailure` with that issue matcher, and `continueAfterFailure` is temporarily true (restored by `defer`). It returns false when the press was not synthesized. - `gate()` uses the helper. It still presses up to 3 times and still requires the value to be `released`/`held`. - `tab()` presses again (at most 3 times) only when the touch was never synthesized and the tab isn't already selected. It still requires `isSelected` within `gateTimeout`. No assertion is loosened, and every other failure during a press still fails the test. **Why `continueAfterFailure` is toggled:** a probe on Xcode 27 showed that, with it false, even an expected (matched) failure stops the test. With it temporarily true, execution continues after a matched failure, and an unmatched failure is still recorded as a test failure.