[Due for payment 2026-05-07] [$250] Chat - Go back to home deeplink opens inbox

[lanitochka17]

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.61-0
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from BrowserStack: https://test-management.browserstack.com/projects/2219752/folder/13176964/test-cases/41237745
Email or phone of affected tester (no customers): N/A
Issue reported by: Applause Internal Team
Bug source: Regression TC Execution
Device used: Windows 11, Chrome
App Component: Chat Report View

Action Performed:

1. Go to https://staging.new.expensify.com/
2. Sign in
3. Open a new tab and navigate to https://staging.new.expensify.com/a/hello
4. Click 'Go back to home page'

Expected Result:

The user is redirected to Home page.

Actual Result:

The user is redirected to Inbox page.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7134933_1776779102458.SFfMhtoQgY.mp4

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @mallenexpensify

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022046608054259865142
• Upwork Job ID: 2046608054259865142
• Last Price Increase: 2026-04-21

[MelvinBot]

Proposal

What is the root cause of that problem?

The URL /a/hello matches the profile route pattern a/:accountID, so it renders ProfilePage with accountID = Number('hello') = NaN. Since NaN fails validation, ProfilePage shows a FullPageNotFoundView with default props — no custom onLinkPress is passed.

The default onLinkPress in FullPageNotFoundView calls Navigation.goBackToHome(), which despite its name, calls goBack(ROUTES.INBOX) — navigating to the Inbox screen instead of the Home screen.

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

Update goBackToHome() in src/libs/Navigation/Navigation.ts to use ROUTES.HOME instead of ROUTES.INBOX. This aligns the function's behavior with its name and the "Go back to home page" button text.

What alternative solutions did you explore? (Optional)

An alternative would be to pass a custom onLinkPress from ProfilePage that navigates to ROUTES.HOME. However, fixing goBackToHome() itself is the better approach since the function name implies it should navigate home, and other callers of this function likely expect the same behavior. NotFoundPage already has a special override that correctly uses ROUTES.HOME for the generic error screen, but that code path isn't hit for profile routes.

---

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.

[melvin-bot]

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

[melvin-bot]

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

[alexanderxfgl-bit]

Proposal

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

When the user clicks "Go back to home page" from the chat report view, they are incorrectly redirected to the Inbox instead of the Home page.

What is the root cause of that problem?

The issue lies within the navigateToAndOpenReport function in src/libs/Navigation/Navigation.ts (line 119). The function checks for a reportID. If it's missing, it navigates to the Inbox. This is incorrect behavior when the intention is to return to the Home screen.

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

Change the else if condition in navigateToAndOpenReport to navigate to ROUTES.HOME instead of ROUTES.INBOX when reportID is null or undefined. This will ensure the user is redirected to the Home screen as expected.

What alternative solutions did you explore? (Optional)

N/A

[alexanderxfgl-bit]

Contributor details
Your Expensify account email: alexanderxfgl@gmail.com
Upwork Profile Link: https://www.upwork.com/freelancers/~2021935202864784599

[melvin-bot]

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

[alexanderxfgl-bit]

Compare branch with the fix: https://github.com/Expensify/App/compare/main...alexanderxfgl-bit/App:fix/88443-ai?expand=1

[ReaperOAK]

Proposal

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

When a signed-in user opens an invalid deeplink such as /a/hello, the app renders a FullPageNotFoundView with a "Go back to home page" link. Clicking that link lands the user on the Inbox screen instead of the Home screen, contradicting the link label and violating the user's expectation.

What is the root cause of that problem?

Two compounding issues in the navigation layer, both in src/libs/Navigation/Navigation.ts:

1. The URL /a/hello matches the dynamic profile route declared in src/ROUTES.ts#L304 (route: 'a/:accountID') and resolves to ProfilePage. Because Number('hello') = NaN, isValidAccountRoute(accountID) returns false, so ProfilePage renders the default FullPageNotFoundView — no custom onLinkPress is forwarded (src/pages/ProfilePage.tsx).

2. The default onLinkPress of FullPageNotFoundView calls Navigation.goBackToHome() (src/components/BlockingViews/FullPageNotFoundView.tsx#L78), but that function is misnamed: it calls goBack(ROUTES.INBOX) — not ROUTES.HOME:

// src/libs/Navigation/Navigation.ts (lines 573-587)
function goBackToHome() {
    const isNarrowLayout = getIsNarrowLayout();
    // This set the right split navigator.
    goBack(ROUTES.INBOX);
    if (!isNarrowLayout) {
        return;
    }
    // This set the right route in this split navigator.
    goBack(ROUTES.INBOX);
}

ROUTES.INBOX ('inbox') and ROUTES.HOME ('home') are two distinct routes registered in src/ROUTES.ts#L175-L176 and mapped to two distinct screens, SCREENS.INBOX and SCREENS.HOME, in src/libs/Navigation/linkingConfig/config.ts#L25. The button's translation key is notFound.goBackHome ("Go back to home page") — so the current behavior is a plain contract violation of the function name and the UI label.

Evidence this is a pre-existing smell: NotFoundPage.tsx already carries a defensive workaround that bypasses goBackToHome() for its generic-error path and calls Navigation.goBack(ROUTES.HOME) directly (src/pages/ErrorPage/NotFoundPage.tsx#L54). That override exists only because goBackToHome() is wrong; no override exists on the ProfilePage code path, which is why this deeplink is still broken.

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

1. Fix goBackToHome() to actually go Home. In src/libs/Navigation/Navigation.ts:

 function goBackToHome() {
     const isNarrowLayout = getIsNarrowLayout();

-    // This set the right split navigator.
-    goBack(ROUTES.INBOX);
+    // This sets the right split navigator.
+    goBack(ROUTES.HOME);

     // We want to keep the report screen in the split navigator on wide layout.
     if (!isNarrowLayout) {
         return;
     }

-    // This set the right route in this split navigator.
-    goBack(ROUTES.INBOX);
+    // This sets the right route in this split navigator.
+    goBack(ROUTES.HOME);
 }

Both goBack calls must be updated. The second call pops within the split navigator on narrow layout and must target the same destination as the first, otherwise narrow-layout users would still land on Inbox.

2. Remove the now-redundant workaround in NotFoundPage.tsx. Once goBackToHome() is correct, the isOnGenericErrorScreen branch no longer needs to bypass it:

-// src/pages/ErrorPage/NotFoundPage.tsx (line 54)
-onLinkPress={isOnGenericErrorScreen ? () => Navigation.goBack(ROUTES.HOME) : fullPageNotFoundViewProps.onLinkPress}
+onLinkPress={fullPageNotFoundViewProps.onLinkPress}

(If the Contributor+ reviewer prefers minimal scope, step 2 can be deferred to a follow-up cleanup PR — step 1 alone fully fixes the reported bug.)

3. Verify the other five call sites are unaffected. Navigation.goBackToHome is invoked by:

• src/components/BlockingViews/FullPageNotFoundView.tsx (default onLinkPress)
• src/pages/workspace/WorkspacePageWithSections.tsx
• src/pages/workspace/WorkspaceInitialPage.tsx
• src/pages/domain/DomainInitialPage.tsx
• src/pages/settings/Subscription/CardSection/CardSection.tsx (after refund request)

All five are semantically "return the user to the app's home landing" after an error or a terminal settings action — none of them want Inbox specifically. Changing the destination to ROUTES.HOME is the intended behavior everywhere.

Regression test (manual, per platform matrix):

1. Sign in, open /a/hello in a new tab → land on NotFoundView.
2. Click "Go back to home page" → URL should become /home, not /inbox.
3. Repeat on narrow layout (mobile web / mWeb) — user should land on Home, not Inbox.
4. Smoke-test the other five call-sites (non-existent workspace URL, non-existent domain URL, refund flow) to confirm they now land on Home.

What alternative solutions did you explore? (Optional)

Alternative A — localize the fix to ProfilePage only by passing a custom onLinkPress={() => Navigation.goBack(ROUTES.HOME)} to FullPageNotFoundView. This is the most minimal patch, but it is strictly worse because:

• It leaves the misnamed goBackToHome() time-bomb in place.
• Four other screens (workspace, domain, card section, the default NotFoundView) remain broken in the exact same way — they all display "Go back to home page" and all land on Inbox. The reporter just happened to find it via the profile route.
• It forces every future caller to remember to override the default, which is exactly the trap that led to the existing NotFoundPage.tsx workaround.

Alternative B — rename goBackToHome() to goBackToInbox() and create a new goBackToHome() that uses ROUTES.HOME. This preserves existing behavior for the five call-sites but requires auditing each one to decide Home vs. Inbox. Given that all five display a "Go back to home page" button (or, for CardSection, complete a refund and should return to the root landing), they all want Home — so renaming buys us nothing and inflates the diff.

The proposed fix is preferred because it corrects the function to match its name and UI label in one surgical change, eliminates the existing workaround in NotFoundPage.tsx, and fixes four additional latent occurrences of the same bug that have simply not been reported yet.