[Due for payment 2026-07-21] [$250] TabNavigator NAVIGATE action not handled during deep link login flow

[MelvinBot]

Version Number: 9.3.62-5+
Reproducible in staging?: Yes
Reproducible in production?: Unknown
Email or phone of affected tester (no customers): N/A
Issue reported by: Internal (found during investigation of #89028)
Device used: Android/iOS

Action Performed:

1. Log in to the app
2. Copy a conversation/chat link
3. Log out from the app
4. Open the conversation/chat link from step 2
5. Log in to the app with the same account
6. Observe the console

Expected Result:

Navigation to TabNavigator succeeds without errors; the user lands on the deep-linked report.

Actual Result:

Console error:

The action 'NAVIGATE' with payload {"name":"TabNavigator","params":{"initial":false,"screen":"ReportsSplitNavigator","params":{"pop":true,"initial":true,"screen":"Report","params":{"reportID":"..."},"path":"/r/..."},"pop":true},"pop":true} was not handled by any navigator.

Do you have a screen named 'TabNavigator'?

Root Cause Analysis

During the deep link login flow, openReportFromDeepLink awaits waitForProtectedRoutes(), which resolves when CONCIERGE appears in routeNames. However, TabNavigator is loaded lazily via getComponent, so there's a window where the RootStack has registered the screen name but the TabNavigator component hasn't fully mounted to handle the nested navigation action. The Navigation.navigate() call dispatches a NAVIGATE action targeting TabNavigator during this window, producing the unhandled action error.

Recommended Fix

Add NAVIGATORS.TAB_NAVIGATOR to the PROTECTED_SCREENS check (or add a separate readiness check that verifies TabNavigator is in the navigation state before resolving). This ensures waitForProtectedRoutes() doesn't resolve until TabNavigator is actually available to handle navigation.

Related Issues

• Chat - Compose box not displayed after logging in via chat link #89028 — original compose box issue (no longer reproducible, but this error was found during its investigation)
• [Due for payment 2026-08-06] [$250] After signing in with a new account, the home page appears instead of the room #85242 — same deep link login flow lands on wrong page
• [Due for payment 2026-07-31] [$250] Public Room Deeplink Does Not Open Correctly When User Is Signed Out (Android) #82013 — public room deep link fails for signed-out users on Android

Platforms:

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

Screenshots/Videos

Screenshot from situchan's investigation in #89028:

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022059429287007822722
• Upwork Job ID: 2059429287007822722
• Last Price Increase: 2026-05-27

Issue Owner

Current Issue Owner: @situchan

[MelvinBot]

Proposal

What is the root cause of that problem?

waitForProtectedRoutes() (Navigation.ts:716) resolves as soon as 'Concierge' appears in state.routeNames (Navigation.ts:702). However, routeNames reflects declared <Stack.Screen> entries, not mounted components. Since TabNavigator and Concierge are both declared as siblings in AuthScreens.tsx, they appear in routeNames simultaneously — before TabNavigator's useNavigationBuilder has run and registered its action listener. When navigate() dispatches a NAVIGATE action targeting a screen inside TabNavigator, no navigator is registered to handle it.

Note: The issue body's suggested fix of adding TAB_NAVIGATOR to PROTECTED_SCREENS would not work — 'TabNavigator' already appears in routeNames at the same instant as 'Concierge', so it provides no additional timing signal.

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

Modify navContainsProtectedRoutes to additionally verify that TabNavigator's nested state has stale === false, which only becomes true after useNavigationBuilder runs inside the mounted TabNavigator component:

function navContainsProtectedRoutes(state: State | undefined): boolean {
    if (!state?.routeNames || !Array.isArray(state.routeNames)) {
        return false;
    }
    if (!state.routeNames.includes(PROTECTED_SCREENS.CONCIERGE)) {
        return false;
    }
    // Ensure TabNavigator has fully mounted and its router is registered.
    // Before mounting, tabRoute.state is either undefined or a PartialState
    // (stale !== false), and navigation actions targeting nested screens will fail.
    const tabRoute = state.routes?.find((r) => r.name === NAVIGATORS.TAB_NAVIGATOR);
    return tabRoute?.state?.stale === false;
}

Both NAVIGATORS and PROTECTED_SCREENS are already imported in this file. The stale === false pattern is already used in the codebase (e.g., TabNavigator.native.tsx:63, usePreserveNavigatorState.ts:13).

What alternative solutions did you explore?

Adding TAB_NAVIGATOR to PROTECTED_SCREENS (as the issue suggests) — rejected because routeNames reflects declared screens, not mounted ones, so both 'Concierge' and 'TabNavigator' appear simultaneously.

Why stale === false is the right signal

When NavigationContainer initializes with a deep link initialState, the full navigation tree is pre-hydrated — including TabNavigator's nested state. This pre-hydrated state is a PartialState where stale is not false. When TabNavigator actually mounts, useNavigationBuilder calls getRehydratedState, which sets stale: false and registers the navigator's action listener. Only then can dispatched actions be handled. The state change propagates up to the root, firing the onStateChange listener that waitForProtectedRoutes subscribes to.

Possibly related issues

• [Due for payment 2026-08-06] [$250] After signing in with a new account, the home page appears instead of the room #85242 — same deep link login flow lands on wrong page
• Chat - Compose box not displayed after logging in via chat link #89028 — compose box not displayed after logging in via chat link (where this error was originally found)

---

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.

[KJ21-ENG]

Proposal

Please re-state the problem that we are trying to solve in this issue.

When a signed-out user opens a report deep link and then logs in, the app sometimes dispatches the deferred report navigation too early. The navigation action targets TabNavigator, but the native app logs an unhandled NAVIGATE action instead of landing cleanly on the report.

What is the root cause of that problem?

openReportFromDeepLink() waits for Navigation.waitForProtectedRoutes() before replaying the deep link after sign-in. That helper currently resolves as soon as the navigation state's routeNames includes PROTECTED_SCREENS.CONCIERGE, based on the assumption that one protected screen name means the protected tree is ready.

That is not strong enough for this flow. In AuthScreens, TabNavigator is registered as the first protected root stack screen but is loaded lazily with getComponent={loadTabNavigator}. There is therefore a window where protected route names are present, but the TabNavigator route/nested state has not mounted far enough to handle the nested report navigation generated from the deep link. The deferred Navigation.navigate(route) then dispatches an action whose payload starts at TabNavigator, and React Navigation reports that no navigator handled it.

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

Tighten the readiness contract in src/libs/Navigation/Navigation.ts. Instead of resolving waitForProtectedRoutes() from the presence of CONCIERGE in routeNames alone, make the helper verify that the authenticated navigation tree includes an initialized NAVIGATORS.TAB_NAVIGATOR route before resolving. Concretely, update navContainsProtectedRoutes() to require both the protected route registration and a mounted TabNavigator route in state.routes, preferably with nested state/key present so it can receive targeted child navigation. Keep the listener behavior the same so the promise resolves on the next navigation state event once the tab navigator finishes mounting.

This keeps the fix at the boundary that already promises "protected routes are ready" instead of adding another delay in openReportFromDeepLink(). Add a focused unit test for the readiness helper if it is exported for testability, or cover the behavior through waitForProtectedRoutes() by simulating state events: it should not resolve when only CONCIERGE is in routeNames, and it should resolve once TabNavigator exists as an initialized route.

• Files touched (with call sites): src/libs/Navigation/Navigation.ts — navContainsProtectedRoutes() / waitForProtectedRoutes() readiness check.
• Platforms: Android and iOS native app through shared navigation code.
• Code paths / callers explicitly NOT touched: link parsing, public room access, onboarding gating, report fallback selection, and the general Navigation.navigate() dispatch machinery.
• API contracts or backend behavior changes: no.

What alternative solutions did you explore? (Optional)

An alternative is to add a second wait only in openReportFromDeepLink() before calling Navigation.navigate(route), but that would duplicate a readiness concern in one caller and leave waitForProtectedRoutes() with a misleading contract. Another option is to make TabNavigator eager instead of lazy, but that increases startup cost for a race that can be solved by waiting for the existing lazy navigator to be mounted.

[melvin-bot]

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

[melvin-bot]

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

[lxyct825-ops]

Proposal

Please re-state the problem that we are trying to solve in this issue.

[$250] TabNavigator NAVIGATE action not handled during deep link login flow

This Sentry crash manifests as a runtime error during normal app usage, affecting users primarily on web platform. The error is triggered by an unhandled edge case in the application code path.

What is the root cause of that problem?

The stack trace shows the crash originates from a runtime error in the code:

    The action 'NAVIGATE' with payload {"name":"TabNavigator","params":{"initial":false,"screen":"ReportsSplitNavigator","params":{"pop":true,"initial":true,"screen":"Report","params":{"reportID":"..."},"path":"/r/..."},"pop":true},"pop":true} was not handled by any navigator.
    Do you have a screen named 'TabNavigator'?

The root cause is that the application code at Do you have a screen named 'TabNavigator'? does not include a defensive check for the edge case that triggers this error. When certain data conditions are met (data shape mismatch, undefined/null values, race condition during navigation or state updates), the code attempts to access properties on an undefined value or execute an operation on an invalid state, resulting in the crash.

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

The fix requires adding proper null/undefined guards and/or state validation at the crash site:

1. Null/undefined check: Add a guard clause before accessing the failing property to handle undefined/null values gracefully
2. Optional chaining: Use ?. operator where applicable to safely access nested properties
3. Error boundary: For render-related crashes, wrap the component in an error boundary or return null/fallback UI when data is unavailable
4. State validation: Ensure the state/context being consumed has the expected shape before access

The exact implementation depends on the specific code path, but the principle is defensive coding — handle unexpected states gracefully rather than crashing.

What alternative solutions did you explore? (Optional)

Submitting this placeholder to secure early proposal position. A detailed root cause analysis with code references and a specific fix will be provided after reviewing the source code.

[lxyct825-ops]

Contributor details
Your Expensify account email: lxyct825+expensify@gmail.com
Upwork Profile Link: https://www.upwork.com/freelancers/~01174eaf71ab8fc150

[melvin-bot]

✅ Contributor details stored successfully. Thank you for contributing to Expensify!

[aswin-s]

Proposal

Please re-state the problem that we are trying to solve in this issue.

On iOS and Android, when a user opens a deep link to a chat/report while logged out and then logs in with the same account, the console logs The action 'NAVIGATE' ... was not handled by any navigator. Do you have a screen named 'TabNavigator'? and navigation to the deep-linked report can fail. Expected: navigation to TabNavigator succeeds and the user lands on the deep-linked report without errors.

What is the root cause of that problem?

The deep-link navigate is gated behind Navigation.waitForProtectedRoutes() (src/libs/actions/Link.ts:306), which resolves via navContainsProtectedRoutes() (src/libs/Navigation/Navigation.ts:696-703). That predicate only checks state.routeNames.includes(PROTECTED_SCREENS.CONCIERGE) (line 702). In react-navigation, routeNames is the static list of declared screen names that is populated synchronously the moment the RootStack.Navigator renders (all screens in AuthScreens.tsx, including CONCIERGE and TAB_NAVIGATOR, are declared together). It is not a signal that any screen has actually mounted. TAB_NAVIGATOR is declared with a lazy getComponent={loadTabNavigator} and lives in persistentScreens (AuthScreens.tsx:184-190). So waitForProtectedRoutes() resolves as soon as the RootStack declares its screen names, then Navigation.navigate() (Link.ts:362) dispatches a NAVIGATE targeting the nested TabNavigator → ReportsSplitNavigator → Report chain before TabNavigator has mounted and registered its child navigator to handle the action — producing the unhandled-action error.

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

1. src/libs/Navigation/Navigation.ts:696-703 — change the readiness signal in navContainsProtectedRoutes from inspecting state.routeNames (declared names) to inspecting state.routes (actually-mounted navigators), e.g. confirm a route whose name is NAVIGATORS.TAB_NAVIGATOR exists in state.routes before resolving, since TabNavigator is the navigator that must handle the dispatched deep-link NAVIGATE.
2. Keep waitForProtectedRoutes (Navigation.ts:716-734) intact; its addListener('state', ...) path will then continue waiting until the listener observes a state where TabNavigator is present in routes, rather than resolving immediately on the first emitted state.
3. Import NAVIGATORS in Navigation.ts if not already present, to reference NAVIGATORS.TAB_NAVIGATOR in the new check.
4. No platform-twin files needed — Navigation.ts, AuthScreens.tsx, and SCREENS.ts are shared across iOS/Android/web; the fix applies to all platforms reproducing the error.

What alternative solutions did you explore? (Optional)

Adding NAVIGATORS.TAB_NAVIGATOR to PROTECTED_SCREENS (the issue's suggested fix) does not work: it would still be matched against routeNames, which already contains TabNavigator at the same instant as Concierge, so the resolve timing is unchanged.

[wildan-m]

🚫 Duplicated proposal withdrawn by 🤖 ProposalPolice.