Repository navigation
flaky: iOS app-build UI tests fail non-deterministically (3 different failures on PR #222) #273
Description
Summary
app-build (.github/workflows/ios.yml) failed 3 times with 3 different test failures on PR #222 (feat(cli): land upstream #1564 display_links on the fork), blocking an unrelated CLI/web/Android feature landing since 2026-10-08.
PR #222 does touch ios/ (it adds DisplayLinksBlockView.swift under ios/Hapi/Features/Chat/Blocks/), so the ios.yml path trigger is legitimately firing — this is not a "wrong check ran" bug. The problem is that the three failing tests are in screens the PR never touches (transcript geometry/typography, tool-transcript presentation, home filter), while the PR's actual iOS surface (chat block rendering) passed every time.
Evidence (3 attempts, 3 different failures, same tip ad7ebce1355a021c9d711c712fb6df6dbf528623)
Run 37758337755, job app-build, run_attempt 1/2/3:
| Attempt | Job ID | Failing test | Assertion |
|---|---|---|---|
| 1 | 113248353763 | ToolTranscriptPresentationTests.testPlanPublicationUpdatesRecyclingAndInspectorPreserveTheDocumentAndAnchor |
XCTAssertNil failed: "<UICollectionViewCell: 0x12603c150; ...>" |
| 2 | 113254031719 | HomeFilterPresentationTests.testFilteringResetsScrollButLiveUpdatesAndChatReturnPreserveIt |
(failed, no further assertion text captured before suite teardown) |
| 3 | 113258706609 | TranscriptTypographyTests.testShrinkingTextClampsAnOffsetBeyondTheNewRowHeight |
XCTAssertEqualWithAccuracy failed: ("196.0") is not equal to ("1.0") +/- ("1.0") |
All three are -only-testing targets of the iPad navigation and layout regression tests step in ios.yml (SessionNavigationTests, SessionSplitPresentationTests, TranscriptTypographyTests, TranscriptGeometryTests) — simulator UICollectionView self-sizing / scroll-restoration tests that are timing-sensitive under CI load. PR #222's diff contains zero changes under ios/Hapi/Features/Transcript/, ios/Hapi/Features/Home/, or the navigation/split-presentation code these suites cover.
Why this is flake, not regression
Evidence bar: "three failures, three different assertions" (different test classes, different failure modes, same commit, no code changes between attempts — these were plain re-runs of the same job on the same SHA). A real regression would reproduce the same failure every attempt.
Impact
PR #222 has been held since 2026-10-08 ($\approx$1 week) on a check that is (a) not exercising the feature it's gating on this tip, and (b) demonstrably non-deterministic. This is exactly the throughput tax the quarantine effort ([tracking issue TBD]) exists to fix.
Candidate causes (not yet root-caused — flag for whoever owns these suites)
- UICollectionView self-sizing / layout completion races under macOS CI runner load (simulator boot + layout pass timing)
- Possible shared-state bleed between
SessionNavigationTests/SessionSplitPresentationTests/TranscriptTypographyTests/TranscriptGeometryTestswhen run together via-only-testingin one invocation
Ask
- Quarantine these three iOS UI tests (or the iPad regression step as a whole) per the quarantine mechanism once it lands, OR fix the underlying timing race
- Separately: evaluate whether
app-buildshould be a required check at all when the PR diff doesn't touch the failing suites' source paths — see companion issue about required-checks scoping
Activity