Native app: tapping Log in on the feed does not reach the sign-in page

[glennmichael123]

Mobile E2E has been red since Chris's 25 Sep rebuild. 01-navigation fails on both platforms at the step that proves a signed-out visitor can get in — the thing a39fa9a6 ("give signed-out users a way to sign in, and test that") was written to guarantee.

[Failed] Native shell navigation (Assertion is false: "Welcome [Bb]ack" is visible)

It is not a slow runner, and not the flow's copy

From the failing run's own step timings (36420991541):

step	result
launchApp	24.3 s
feed visible	9.1 s
assertNotVisible Menu / Record	1.4 s each
tapOn "^Log in$"	COMPLETED, 2.9 s
wait for "Welcome [Bb]ack"	FAILED after 31.7 s

The tap succeeded. The screenshot captured 30 seconds later shows the feed unchanged, with Log in still in the header. The device log shows no crash — the app and the WebView are alive throughout. The view hierarchy at that moment has exactly one element named Log in, the header link at [333,77][374,98], so there is no ambiguity about what was tapped.

What it is not

• Not the assertion. Welcome [Bb]ack still exists in both login.stx and AuthGate.stx; tests/unit/mobile-e2e-copy.test.ts passes.
• Not the browser. At 375×812 in a desktop browser against the QA stack, clicking that same header link navigates to /login and the title becomes Log In — Wildloop. No console errors.
• Not the backend commits. It passed on ac173724. Everything of mine since (012a5f10, 872dcbd8) is the elevation backfill, the scheduler and cloud config — nothing that reaches the frontend bundle.

Between the last green run and now, the frontend changed only in ede87f99, ee9bd40a, 95325716 and 11711421 — feed.stx alone is +546/-165, and the feed is the page the tap happens on.

Lead, unconfirmed

scripts/run-mobile-e2e.ts → validateNativeTabLinks() already asserts that the header's /feed, /notifications and /settings links must do document navigation, because "an SPA fragment swap may leave that page's client module unexecuted". The header's /login link is the one link in that header the validator does not check. mobile-header.stx:40 carries no router opt-out.

I could not confirm this from outside the shell: stx's shouldIntercept() intercepts an internal route only when getContainer() finds a router container, and whether the bundled WebView has one needs a device to answer. So this is a lead, not a diagnosis — worth starting from, not worth shipping on.

Next step

Reproduce with bun run preview:ios and watch what the tap does in the shell. If it is the router, the fix is an opt-out on that link plus /login added to validateNativeTabLinks() so the gap cannot reopen.

[glennmichael123]

I got this wrong. It is a flaky test, not a regression, and the headline of this issue is false.

Reproduced on a real simulator, on a9857148, with the bundled build — the same configuration CI uses. Tapped Log in at (353, 87), the coordinates CI's own failure hierarchy gave for that element. It navigated straight to the sign-in page: "Welcome Back". A signed-out visitor can reach sign-in from the feed.

The CI history says the same thing once you look at more than one run:

88ed3d5f  success
5adb4e31  success
872dcbd8  failure   <- the run this issue was filed from
012a5f10  success

Three passes around one failure. I filed this after looking at a single red run and asserted "Mobile E2E has been red since Chris's 25 Sep rebuild", which was wrong — what had been red since then was 03-offline-bundle, on copy the views no longer rendered, and that was fixed in ac173724. Once the flows stopped failing at their first step, 01-navigation began running to completion, and it has passed every time since except once.

So what is real is much smaller: that step flaked once in four runs. The evidence from the failing run still stands on its own — the tap completed in 2.9s, the app did not crash, and 30 seconds later the screenshot showed the feed unchanged — which points at the navigation not completing within the wait on a loaded runner rather than at a dead link. The feed got substantially heavier in 11711421, which is a plausible reason a cold WebView needs longer, and 01-navigation already raises its other wait to 90s for exactly that reason.

Closing rather than leaving a false claim open. If that step flakes again, the cheap fix is raising its 30s wait to match the 90s the same flow already uses for the feed — but I would rather see it fail twice than pre-emptively loosen a real assertion.

Separately, and genuinely broken: the bundled build has no Google sign-in button. dist/login.html contains "Or continue with" and the Apple button but no auth/google/redirect, so @if(googleReady) evaluated false during the static build even though the same config reads configured: true in an ordinary process and production serves the button correctly. Raised on #970 rather than here.