[$250] Email - Tapping back arrow, endless loading with blank page is displayed instead Home page

[jponikarchuk]

If you haven’t already, check out our contributing guidelines for onboarding and email contributors@expensify.com to request to join our Slack channel!

---

Version Number: v9.3.69-3
Reproducible in staging?: Yes
Reproducible in production?: No
If this was caught during regression testing, add the test name, ID and link from BrowserStack: https://test-management.browserstack.com/projects/2219752/folder/13176726/test-cases/41237088
Email or phone of affected tester (no customers): lattelover1412+09054@gmail.com
Issue reported by: Applause Internal Team
Bug source: Regression TC Execution
Device used: android
App Component: Other

Action Performed:

Setup - Can be executed in a Secondary device or browser

1. Log in as an admin of a workspace or create one
2. Click on the Invite Member button
3. Add an email address that does not have an Expensify account >> set Admin Role
4. Click Invite (Should be a real account with an inbox that can receive the invite)

Main Device

1. User is not logged in
2. Open the email inbox of the invited user
3. Click on the bottom link "Open it in Expensify"
4. Verify that you are redirected to the workspace chat
5. Tap back arrow (the top left) to return Home page

Expected Result:

A blank page should not be displayed, and appropriate page with bottom button (Home, Account, Spend, etc) should be displayed after user tap back arrow

Actual Result:

Endless loading with white blank page displayed, user is not able to proceed further steps.
Note: close the app and relaunch, user is able to open Home page

Workaround:

Unknown

Platforms:

• Android: App
• Android: mWeb Chrome
• iOS: App
• iOS: mWeb Safari
• iOS: mWeb Chrome
• Windows: Chrome
• MacOS: Chrome / Safari

Screenshots/Videos

Video.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022053692491034956430
• Upwork Job ID: 2053692491034956430
• Last Price Increase: 2026-05-18

Issue Owner

Current Issue Owner: @paulnjs

[MelvinBot]

Proposal

What is the root cause of that problem?

When a new user opens a workspace invite email link ("Open it in Expensify"), the app navigates via a transition URL with exitTo=/r/REPORTID. Two competing navigation paths race against each other:

1. setUpPoliciesAndNavigate fires immediately when AuthScreens mount and calls Navigation.navigate(exitTo) via waitForProtectedRoutes().
2. LogOutPreviousUserPage is delayed because signInWithShortLivedAuthToken sets account.isLoading = true, blocking its goBack(ROUTES.HOME) call that would remove the TRANSITION_BETWEEN_APPS screen.

Because setUpPoliciesAndNavigate fires first while TRANSITION_BETWEEN_APPS is still on top of the root stack, linkTo sees the top route is NOT TAB_NAVIGATOR and PUSHes a new TAB_NAVIGATOR above it. This creates a corrupted root state: [TAB_NAVIGATOR, TRANSITION_BETWEEN_APPS, TAB_NAVIGATOR(REPORTS_SPLIT > [REPORT])].

Additionally, SplitRouter.adaptStateIfNecessary checks rootState.routes.length === 1 to decide if this is an initial route. With 3 routes in the root state, isInitialRoute is false, so on narrow layout (Android phone) the INBOX sidebar is NOT added to the split navigator — it only contains [REPORT].

When the user taps the back arrow (ReportHeader.tsx:49-71), GO_BACK can't be handled by the split (no sidebar to pop to), so it bubbles up and pops the root stack — revealing the TRANSITION_BETWEEN_APPS screen, which renders FullScreenLoadingIndicator — the endless blank loading page.

What changes do you think we should make in order to solve the problem?

In linkTo, when the current top route is TRANSITION_BETWEEN_APPS and we're navigating to TAB_NAVIGATOR, we should use REPLACE instead of PUSH. This ensures the transition screen is removed from the stack rather than having a new TAB_NAVIGATOR pushed on top of it:

// Pseudo-code change in linkTo/index.ts around line 210-213
if (currentTopRoute?.name === SCREENS.TRANSITION_BETWEEN_APPS && typedPayload.name === NAVIGATORS.TAB_NAVIGATOR) {
    action.type = CONST.NAVIGATION.ACTION_TYPE.REPLACE;
} else if (currentTopRoute?.name !== NAVIGATORS.TAB_NAVIGATOR && typedPayload.name === NAVIGATORS.TAB_NAVIGATOR) {
    action.type = CONST.NAVIGATION.ACTION_TYPE.PUSH;
}

This way the TRANSITION_BETWEEN_APPS screen is properly replaced by the TAB_NAVIGATOR containing the report, the root state stays clean ([TAB_NAVIGATOR, TAB_NAVIGATOR(REPORTS_SPLIT)]), isInitialRoute remains correct, and back navigation works as expected.

What alternative solutions did you explore?

An alternative would be to fix the timing in LogOutPreviousUserPage so that goBack(ROUTES.HOME) fires before setUpPoliciesAndNavigate navigates. However, this is fragile since it depends on the timing of account.isLoading being set back to false, and could break other transition flows. The linkTo fix is more defensive — it handles the corrupted state at the navigation layer regardless of which path fires first.

Investigation details

Evidence chain:

1. Email invite link uses a transition URL → TRANSITION_BETWEEN_APPS screen mounts and renders FullScreenLoadingIndicator
2. signInWithShortLivedAuthToken is called at LogOutPreviousUserPage.tsx:60, setting account.isLoading = true
3. The second useEffect at LogOutPreviousUserPage.tsx:66-84 is blocked by isAccountLoading check on line 74
4. Meanwhile, setUpPoliciesAndNavigate fires and navigates to /r/REPORTID
5. linkTo at line 211 sees TRANSITION_BETWEEN_APPS on top → PUSHes new TAB_NAVIGATOR
6. Root state becomes [TAB_NAVIGATOR, TRANSITION_BETWEEN_APPS, TAB_NAVIGATOR(REPORTS_SPLIT > [REPORT])]
7. SplitRouter.ts:49: rootState.routes.length = 3 → isInitialRoute = false → no sidebar added on narrow layout
8. Back press pops root stack → exposes TRANSITION_BETWEEN_APPS → endless loading

Why Android-only: The isNarrowLayout check in adaptStateIfNecessary means the sidebar IS added on wide layouts (web/tablet), so GO_BACK is handled within the split navigator. On narrow layout (Android phone), the sidebar is skipped, causing GO_BACK to bubble to the root.

Why staging but not production: The linkTo PUSH logic at line 210-213 and the isInitialRoute check in SplitRouter appear to be recent additions to the navigation system that exist in staging but may not yet be in the production build.

---

Next Steps for Contributor+ team: Reply with @MelvinBot implement this to create a draft PR, @MelvinBot <your feedback> to refine this analysis, or explain why you are rejecting Melvin's proposal.

[mukhrr]

Proposal

What is the root cause of that problem?

The workspace-invite email on Android opens the link inside HybridApp. OldDot consumes the magic link, then hands off to NewDot via the TRANSITION_BETWEEN_APPS route with exitTo=r/<reportID>. That route is rendered by LogInWithShortLivedAuthTokenPage, and the handoff to the workspace chat happens here:

src/pages/LogInWithShortLivedAuthTokenPage.tsx#L64-L70

if (exitTo) {
    Navigation.isNavigationReady().then(() => {
        // We must call goBack() to remove the /transition route from history
        Navigation.goBack();
        Navigation.navigate(exitTo as Route);
    });
}

The intent of goBack() here is to pop the /transition screen, but it runs while the navigator tree is still mid-switch from the Public stack (where TRANSITION_BETWEEN_APPS lives) to the Protected stack — so the pop is a no-op on the resulting Protected stack. Navigation.navigate(exitTo) then pushes the workspace report on top, leaving the still-mounted LogInWithShortLivedAuthTokenPage in the back history.

That page renders only <FullScreenLoadingIndicator /> while account?.isLoading is true (LogInWithShortLivedAuthTokenPage.tsx#L75-L83), and its only navigation effect re-runs solely when route changes (L24-L73). When the user taps the back arrow on the workspace chat, react-navigation pops back to this still-mounted transition screen; route hasn't changed, the effect doesn't re-fire, and the user is stranded on the white full-screen loader — exactly the "endless loading / blank page" reported. Killing and relaunching the app skips this entry, which matches the "close the app and relaunch" workaround.

This shows up on Android only because that's where the HybridApp transition flow runs for this email link in v9.3.69-3 (iOS doesn't currently go through LogInWithShortLivedAuthTokenPage for this entry point, and standalone NewDot uses ValidateLoginPage which routes through a different handler).

What changes do you think we should make in order to solve the problem?

I'd replace the brittle goBack() + navigate() with a single navigate(exitTo, {forceReplace: true}), so the workspace chat takes the place of the transition screen in the stack instead of being pushed on top of it. The same pattern is already used a few lines above for the SAML branch (L53), so this just brings the exitTo path in line with it.

 if (exitTo) {
     Navigation.isNavigationReady().then(() => {
-        // We must call goBack() to remove the /transition route from history
-        Navigation.goBack();
-        Navigation.navigate(exitTo as Route);
+        // We must replace to remove /transition route from history
+        Navigation.navigate(exitTo as Route, {forceReplace: true});
     });
 }

The same anti-pattern also exists for the support-auth branch at L35-L39 (goBack() then navigate(ROUTES.HOME)); I'd apply the same forceReplace fix there for consistency, even though it's outside this specific repro.

What alternative solutions did you explore? (Optional)

1. Dispatch StackActions.pop explicitly targeting TRANSITION_BETWEEN_APPS before navigating. Works, but it pokes navigator internals and only handles this one screen, while forceReplace is the existing generic primitive for "swap the current entry" — and is already used at L53 for SAML.
2. Make the page's effect re-fire on focus (useFocusEffect instead of useEffect). This would un-stick the loader, but on every back tap the user would briefly see the loader and then be re-navigated to the workspace chat — they'd never actually reach Home, which is the expected behavior in the report.
3. Also fix handleExitToNavigation in src/libs/actions/Session/index.ts (same goBack(); navigate() shape). Worth doing as a follow-up to harden the standalone/iOS ValidateLoginPage path, but it isn't required for the Android repro in this issue.

[Abdukhamid000]

Proposal

What is the root cause of that problem?

When the user opens the invitation email and taps "Open it in Expensify," the link contains a magic-code URL (v/{accountID}/{validateCode}?exitTo=r/{reportID}). Because VALIDATE_LOGIN is listed as a public screen, getAdaptedStateFromPath returns only [VALIDATE_LOGIN] — no home screen is injected underneath it.

After the user signs in, handleExitToNavigation runs:

https://github.com/Expensify/App/blob/main/src/libs/actions/Session/index.ts#L1410-L1418

It calls Navigation.goBack() (which silently does nothing — VALIDATE_LOGIN is the root route, so canGoBack() is false) and then Navigation.navigate(exitTo) to open the workspace chat.

Inside linkTo, the following block intercepts that navigation:

https://github.com/Expensify/App/blob/main/src/libs/Navigation/helpers/linkTo/index.ts#L208-L213

Because VALIDATE_LOGIN is the current top route (not TAB_NAVIGATOR), and the destination is TAB_NAVIGATOR, the action type is forced to PUSH. This stacks the report screen on top of the validate-login screen, producing:

[VALIDATE_LOGIN, TAB_NAVIGATOR → REPORT]

When the user taps the back arrow from the workspace chat, the TAB_NAVIGATOR is popped and VALIDATE_LOGIN is revealed — showing its FullScreenLoadingIndicator with no forward navigation, leaving the user stuck on a blank loading screen.

What changes do you think we should make in order to solve the problem?

The PUSH override at lines 208–213 in linkTo/index.ts was added to preserve tab context when an RHP overlay sits above a TAB_NAVIGATOR. It is too broad and incorrectly applies to VALIDATE_LOGIN, which should never remain in the back stack after the user signs in.

I think we should change the condition so it only forces PUSH when a RIGHT_MODAL_NAVIGATOR (or another overlay type that belongs in the back stack) is already above a TAB_NAVIGATOR, and uses REPLACE when navigating away from VALIDATE_LOGIN. This ensures VALIDATE_LOGIN is swapped out rather than buried underneath the new screen.

The same guard should be applied for TRANSITION_BETWEEN_APPS to prevent a symmetrical blank-screen issue if the user navigates back through that screen.

What alternative solutions did you explore?

I considered fixing this in handleExitToNavigation by calling navigationRef.resetRoot(getAdaptedStateFromPath(exitTo)) instead of goBack() + navigate(). That would directly reset the stack to the correct home + report state, bypassing the PUSH logic entirely. The downside is that it couples the Session action layer to navigation internals, and it only fixes the validate-login entry point — any other transient screen that ends up as the sole root route would still cause the same regression. Fixing it in linkTo addresses the root cause once for all callers.

[melvin-bot]

Triggered auto assignment to Contributor-plus team member for initial proposal review - @daledah (External)

[KJ21-ENG]

🚫 Duplicated proposal withdrawn by 🤖 ProposalPolice.

[neerajbachani]

Proposal

What is the root cause of that problem?

The app can skip loading the deep-linked workspace chat at a critical moment, then never retry.

When a user opens the invite link while logged out, the app starts a deep-link open flow and routes to a report screen. In ReportFetchHandler, there is a guard that intentionally returns early during onboarding while isLoadingApp is still true (added to avoid a different onboarding timing bug).
In this specific flow, that early return can happen once, but the effect that calls fetchReport() is not guaranteed to run again when loading state becomes ready. That leaves report loading state unresolved (isLoadingInitialReportActions / related loading flags), so the user sees endless loading / blank content.

Back navigation makes this feel worse: in some report/not-found paths, back uses Navigation.goBack() with no fallback route. If the stack has no valid previous route, back can no-op, so the user remains stuck on the blank/loading surface.

What changes do you think we should make in order to solve the problem?

1. Add a deterministic retry trigger after the onboarding/loading guard unblocks in ReportFetchHandler.

• Keep the existing guard (to preserve the earlier onboarding fix intent).
• If a deep-linked report fetch was skipped due to isLoadingApp + onboarding conditions, run openReport() once when prerequisites become ready.
• Make it one-shot per route/report transition to avoid duplicate openReport() calls.

2. Keep deep-link behavior stable for logged-out users.

• Do not change URL parsing or anonymous access rules.
• Only fix the missed transition from “guard blocked” to “fetch allowed”.

3. Add a safe back fallback for deep-link dead-end states.

• In report/back entry points (including not-found back handler), use a fallback route (home/split root) when canGoBack() is false.
• This prevents users from getting stuck even if a stack pop is unavailable.

4. Add regression coverage.

• Test deep-link to r/:reportID while logged out/onboarding.
• Verify fetch is deferred (when blocked) and then executed once loading completes.
• Verify back from deep-linked report lands on a valid screen when no prior stack exists.

What alternative solutions did you explore? (Optional)

• Only patch back behavior: improves recovery UX but does not fix the underlying endless-loading state.

• Route all failures to Concierge/last accessed report: hides the bug and can send users to the wrong place after a valid workspace invite link.

[melvin-bot]

Job added to Upwork: https://www.upwork.com/jobs/~022053692491034956430

[github-actions]

⚠️ @Abdukhamid000 Thanks for your proposal. Please update it to follow the proposal template, as proposals are only reviewed if they follow that format (note the mandatory sections).