Android - Expense - Back button returns to LHN after splitting expense

[applause-bot]

If you haven’t already, check out our contributing guidelines for onboarding. To join our Slack channel, fill out this form.

---

Version Number: 9.4.45-1
Reproducible in staging?: Yes
Reproducible in production?: N/A - new feature, doesn't exist in prod
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #92546
Email or phone of affected tester (no customers): sdsjodijnsdojsosjio@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Samsung Galaxy S25 FE / Android 16
App Component: Money Requests

Action Performed:

1. Launch Expensify app.
2. Go to workspace chat.
3. Create two expenses.
4. Tap on any expense preview.
5. Tap More > Split > Save.
6. Tap app back button.

Expected Result:

App will return to workspace chat.

Actual Result:

App returns to LHN.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7219392_1785212742235.Screen_Recording_20260728_121525_Expensify.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Julia Ponikarchuk
Bug ID: 7219392

[applause-bot]

While Applause doesn't embed attachments for this bug, here are the links for quick view:
https://platform.applause.com/services/links/v1/external/9e2fe4b1b7268d7894959f9c7ba5f818d7a70c131469e28bf71f416bda97d4f3

[melvin-bot]

You have been assigned to this deploy blocker because you recently merged this PR: #92546

[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]

🔍 Investigation Summary

Classification: Frontend bug
Causing PR: #92546 - "Navigate to the clicked expense in a multi-expense report preview" by @wildan-m (High confidence)
Related Issues: #91042 (the issue #92546 fixed)

Recommendation: REVERT

This PR added a brand-new, native-only navigation path (openExpenseOverParentReport) that builds the expense stack by splicing a keyless parent-report route beneath the expense. That spliced route does not survive the Split RHP dismiss/reset, so hard-back from the expense skips the workspace chat and lands on the LHN. The regression is squarely inside this PR's new code and reverting cleanly restores the prior (correct) behavior; a targeted fix is possible but riskier to land under deploy-blocker time pressure (see below).

Assigned: @wildan-m (PR author), @jayeshmangwani (approving reviewer), @MonilBhavsar (approving reviewer) from the highest-confidence causing PR.
Labels: No label changes. DeployBlockerCash is kept because this is a Frontend bug with a clear App causing PR. DeployBlocker (Web) is not present and was not added.

📋 Detailed Analysis

Evidence

• The repro requires two expenses (step 3), which renders the multi-expense report preview carousel. Tapping a card is exactly the flow Navigate to the clicked expense in a multi-expense report preview #92546 introduced.
• On Android native narrow layout, tapping a card routes through the new branch Navigation.openExpenseOverParentReport(iouReportID, childReportID, backTo) in MoneyRequestReportPreview/index.tsx (see line 244). With a single expense the code falls back to the old openReportFromPreview() (line ~181 branch), which is why the bug only appears with 2+ expenses.
• openExpenseOverParentReport is referenced only from MoneyRequestReportPreview/index.tsx — it is net-new code owned entirely by this PR, so no other StagingDeployCash PR can be responsible for this path.
• Symptom is staging-only / not in production because this is a new feature shipped by Navigate to the clicked expense in a multi-expense report preview #92546 (consistent with the issue's "N/A - new feature" field).

Verification

• Affected files (both introduced/modified by Navigate to the clicked expense in a multi-expense report preview #92546):
  • src/libs/Navigation/Navigation.ts — new openExpenseOverParentReport (lines ~1256-1300), exported at line 1307.
  • src/components/ReportActionItem/MoneyRequestReportPreview/index.tsx — new navigateToExpense / openTransactionFromPreview calling into it (line 244).
• Confirmed via gh pr view 92546 --json files: the PR modifies exactly these two files (plus tests and cspell.json).
• Confirmed via grep that openExpenseOverParentReport has a single caller, so the regression cannot originate elsewhere.

Root Cause

openExpenseOverParentReport (native narrow layout) first does navigate(expenseRoute) and then, one microtask later, splices the parent report beneath the expense with a targeted reset:

const routes = [...splitState.routes.slice(0, -1), {name: SCREENS.REPORT, params: {reportID: parentReportID, backTo}}, topRoute];
navigationRef.dispatch({ ...CommonActions.reset({...splitState, routes, index: routes.length - 1}), target: splitState.key });

The inserted parent-report route is intentionally keyless (the PR's own eslint-disable comment notes "the inserted parent route is keyless; react-navigation mints its key on reset"). The intended real state is [..., chat, report, expense] so that back pops expense → report → chat.

The Split flow (More > Split > Save) opens the SplitExpense RHP and, on Save, calls Navigation.dismissToPreviousRHP() (SplitExpensePage.tsx line ~354), which performs its own modal dismiss/reset over this ReportsSplitNavigator state. The keyless spliced parent-report entry does not reliably survive that reset, so after Save the stack effectively collapses back toward [..., chat, expense] (or loses the report anchor entirely). Pressing the app back button from the expense therefore has no intermediate report route to land on and the navigator falls through to the sidebar/LHN instead of the workspace chat — the reported EXPECTED vs ACTUAL.

Because the broken behavior is produced entirely by this PR's new native navigation construction, the safest resolution is to revert #92546. If the team prefers ROLL FORWARD, the targeted fix would be to give the spliced parent-report route a stable key (or reconstruct the report entry so it survives the Split RHP dismiss), but that should be validated specifically against the Split > Save > back flow on Android native before shipping.

[IuliiaHerets]

Reproduced on Samsung Galaxy A40/Android 11/App/Build v9.4.45-1

MicrosoftTeams-video.11.mp4

[MonilBhavsar]

@MelvinBot please check why revert didn't fix this issue