Deeplink - Finish onboarding flow, app not respond when tap back button of Concierge chat

[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.70-1
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/test-runs/TR-28061/folder/13176964/41237739/1407058224
Email or phone of affected tester (no customers): lekima20+67005@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: iPhone 16 pro/ 26.4.2
App Component: Other

Action Performed:

Precondition:

• Log out of NewDot
• Force close the app (important)

1. From note tap on the link https://staging.new.expensify.com/concierge
2. Sign-up new account and complete onboarding flow
3. Tap back button of Concierge chat

Expected Result:

App should back to Homepage

Actual Result:

App not respond when tapping on back button of Concierge chat. This issue not occur if log out New Dot and not force close the app

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

[melvin-bot]

Triggered auto assignment to @nkuoch (DeployBlockerCash), see https://stackoverflowteams.com/c/expensify/questions/9980/ for more details.

[melvin-bot]

💬 A slack conversation has been started in #expensify-open-source

[github-actions]

👋 Friendly reminder that deploy blockers are time-sensitive ⏱ issues! Check out the open `StagingDeployCash` deploy checklist to see the list of PRs included in this release, then work quickly to do one of the following:

1. Identify the pull request that introduced this issue and revert it.
2. Find someone who can quickly fix the issue.
3. Fix the issue yourself.

[MelvinBot]

Proposal

What is the root cause of that problem?

After completing onboarding via a deep link to /concierge, the navigation stack has no home/LHN screen underneath the Concierge report, so the back button has nowhere to go.

Here's what happens step by step:

1. App is force-closed, then opened via deep link staging.new.expensify.com/concierge
2. User is unauthenticated → signs up → onboarding begins via startOnboardingFlow, which calls resetRoot() appending the OnboardingModalNavigator on top of existing routes
3. Onboarding completes → navigateAfterOnboardingWithMicrotaskQueue calls dismissModal() (pops the onboarding navigator) then calls navigateAfterOnboarding()
4. getReportIDAfterOnboarding on small screens explicitly excludes Concierge chat and self-DM (line 51). For a fresh signup with no other reports, it returns undefined → no navigation happens
5. The deferred deep link handler in Link.ts eventually fires and navigates to /concierge → ConciergePage calls navigateToConciergeChat with shouldDismissModal=true → this uses dismissModalWithReport which pops the CONCIERGE screen (it's in MODAL_ROUTES_TO_DISMISS) and navigates to the report
6. Final state: ReportsSplitNavigator with only the Concierge report screen — no sidebar/home entry in the stack on narrow screens
7. Back button calls goBack() → canGoBack() returns false → back press is silently ignored

The core problem is that neither navigateAfterOnboarding nor the deferred deep link handler ensures the home/LHN screen exists in the navigation stack before navigating to the Concierge report on small screens.

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

In navigateAfterOnboarding, when getReportIDAfterOnboarding returns undefined on small screens, the function should navigate to the home/inbox route (e.g., ROUTES.INBOX) as a fallback instead of doing nothing. This ensures the navigation stack always has a proper base after onboarding completes, regardless of whether a deep link is pending.

Alternatively (or additionally), the post-onboarding flow could use Navigation.resetToHome() before navigating to the target report, ensuring the home screen is always the base of the stack on small screens.

What alternative solutions did you explore? (Optional)

• Modifying the deferred deep link handler in Link.ts to ensure home is in the stack before navigating to Concierge — this would fix the deep link case but not other post-onboarding navigation edge cases where no report is found.
• Changing ConciergePage to not use shouldDismissModal=true — this would leave the CONCIERGE screen in the stack but wouldn't properly solve the back navigation issue since CONCIERGE itself is a redirect screen, not a destination.

---

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.

[OSBotify]

Investigation Summary

Classification: Frontend bug
Causing PR: #86390 - "Preserve deep-linked report route during onboarding guard redirect" by @bernhardoj (High confidence)
Related Issues: #85242, #86258

Recommendation: REVERT

PR #86390 removes the Navigation.navigate(ROUTES.HOME) fallback from navigateAfterOnboarding.ts and SignInModal.tsx, which leaves the navigation stack with no HOME entry to go back to after onboarding completes on mobile.

Assigned: @bernhardoj (PR contributor), @FitseTLT, @Valforte, @marcochavezf (approving reviewers) from PR #86390
Labels: No label changes made — DeployBlockerCash is correctly applied (App repo fix required)

Detailed Analysis

Evidence

The exact navigation flow that produces the bug:

1. User force-closes the app, then taps https://staging.new.expensify.com/concierge
2. App starts fresh with SCREENS.CONCIERGE as the initial route in the navigation stack
3. OnboardingGuard fires a REDIRECT to onboarding/purpose → handleNavigationGuards is called
4. isModalRedirect = true (target is ONBOARDING_MODAL_NAVIGATOR)
5. existingFullScreenRoute = state.routes.findLast(route => isFullScreenName(route.name))
   • SCREENS.CONCIERGE is NOT in FULL_SCREENS_SET (that set contains the values from SIDEBAR_TO_SPLIT, SEARCH_FULLSCREEN_NAVIGATOR, TAB_NAVIGATOR, HOME, and WORKSPACE_NAVIGATOR)
   • So existingFullScreenRoute is undefined
6. resetRoutes falls back to the full redirect state: [HOME, OnboardingModalNavigator]
7. User signs up, completes onboarding → navigateAfterOnboardingWithMicrotaskQueue is called
8. Navigation.dismissModal() pops OnboardingModalNavigator → state is [HOME]
9. For mobile with TRACK_EXPENSES_WITH_CONCIERGE variant (the default for new sign-ups on mobile): Navigation.navigate(ROUTES.REPORT_WITH_ID.getRoute(conciergeReportID)) is called
10. This navigate call replaces HOME in the stack (does not push) → state is [REPORTS_SPLIT_NAVIGATOR(concierge)]
11. User is in the Concierge chat with no prior entries in the navigation history → canGoBack() returns false → back button has no effect

Why force-close matters: When the app is NOT force-closed (just logged out), there are previous navigation entries that survive in the stack, so canGoBack() returns true and the back button works. Only with a completely fresh start via the deep link does the problem manifest.

What PR #86390 changed:

In navigateAfterOnboarding.ts, before PR #86390:

if (reportID) {
  Navigation.navigate(ROUTES.REPORT_WITH_ID.getRoute(reportID));
} else {
  // Navigate to home to trigger guard evaluation
  Navigation.navigate(ROUTES.HOME);
}

After PR #86390, the else branch was removed entirely. For the TRACK variant on mobile, navigateAfterOnboarding takes the early return path (Navigation.navigate(conciergeReportID)), so the removed else branch is not the issue for this specific path — but the Navigation.navigate(ROUTES.HOME) removal from SignInModal.tsx is relevant for other paths.

The deeper issue: after Navigation.dismissModal() removes OnboardingModalNavigator, state is [HOME]. Then Navigation.navigate(ROUTES.REPORT_WITH_ID.getRoute(conciergeReportID)) replaces HOME with REPORTS_SPLIT_NAVIGATOR(concierge) at the same stack level, leaving a stack of depth 1 with no route to go back to.

Why this was not caught when PR #85556 (the original version of this PR) was merged in March: The revert of PR #85556 (via PR #86307) was for a different reason (double Expensify logos on the work email modal). The back button issue on Concierge after a forced deep-link onboarding may have existed in that original version too, but was not surfaced before the revert for different reasons.

Secondary contributing factor: PR #88796 added TRACK_PERSONAL as a new onboarding choice that also routes to TRACK_EXPENSES_WITH_CONCIERGE on mobile, expanding the set of users who hit this navigation path. However, the existing TRACK_WORKSPACE/TRACK_BUSINESS choice already hit this same path, so PR #86390 is the primary cause.

Verification

Affected files:

• src/libs/navigateAfterOnboarding.ts — modified by PR Preserve deep-linked report route during onboarding guard redirect #86390 (removed else { Navigation.navigate(ROUTES.HOME); })
• src/pages/signin/SignInModal.tsx — modified by PR Preserve deep-linked report route during onboarding guard redirect #86390 (removed Navigation.navigate(ROUTES.HOME) after dismissal)
• src/libs/Navigation/AppNavigator/createRootStackNavigator/RootStackRouter.ts — modified by PR Preserve deep-linked report route during onboarding guard redirect #86390 (the handleNavigationGuards logic for modal redirect and fullscreen route preservation)

PR #86390 modifies all three of these files, which are central to the navigation stack management during and after the onboarding flow.

Confirmation that SCREENS.CONCIERGE is not a fullscreen name:
FULL_SCREENS_SET in src/libs/Navigation/helpers/isNavigatorName.ts is defined as:

const FULL_SCREENS_SET = new Set([
  ...Object.values(SIDEBAR_TO_SPLIT),
  NAVIGATORS.SEARCH_FULLSCREEN_NAVIGATOR,
  NAVIGATORS.TAB_NAVIGATOR,
  SCREENS.HOME,
  NAVIGATORS.WORKSPACE_NAVIGATOR,
]);

SIDEBAR_TO_SPLIT maps to REPORTS_SPLIT_NAVIGATOR, SETTINGS_SPLIT_NAVIGATOR, etc. — not SCREENS.CONCIERGE. This means the "preserve existing fullscreen route" branch in handleNavigationGuards does NOT fire for the /concierge deep link, and the issue is NOT that an incorrect route is preserved.

The navigate call replaces HOME: Navigation.navigate(ROUTES.REPORT_WITH_ID.getRoute(conciergeReportID)) navigates to a fullscreen route (REPORTS_SPLIT_NAVIGATOR) from within another fullscreen route (HOME). In linkTo, navigating between fullscreen routes uses NAVIGATE (replace) rather than PUSH, resulting in a single-entry stack with no way to go back.

Root Cause

PR #86390 removed the else { Navigation.navigate(ROUTES.HOME); } fallback from navigateAfterOnboarding.ts and removed Navigation.navigate(ROUTES.HOME) from SignInModal.tsx. While the stated intent was to fix the navigation state after a deep-linked sign-up flow, a side effect is that on mobile when a new user enters via the /concierge deep link, signs up, and completes onboarding with the TRACK_EXPENSES_WITH_CONCIERGE variant, navigateAfterOnboarding calls Navigation.navigate(ROUTES.REPORT_WITH_ID.getRoute(conciergeReportID)) which replaces the HOME route (the only entry in the stack at that point). The resulting stack has depth 1, so canGoBack() is false and the back button has no effect.