[Due for payment 2026-08-05] Expense - Merged expense opens on Spend after merging expenses on Inbox

[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-0
Reproducible in staging?: Yes
Reproducible in production?: No
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #96897
Email or phone of affected tester (no customers): sjdoinjsdoiosjdisojdiso1@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Mac 26.5 / Chrome
App Component: Money Requests

Action Performed:

1. Go to staging.new.expensify.com
2. Go to workspace chat.
3. Create two expenses.
4. Open the report.
5. Open any expense.
6. Click More > Merge.
7. Complete merging with another expense.

Expected Result:

Merged expense will open on Inbox after merging expenses on Inbox.

Actual Result:

Merged expense opens on Spend after merging expenses on Inbox.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7219097_1785179344194.2.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Svetlana Lazutkina
Bug ID: 7219097

Issue Owner

Current Issue Owner: @suneox

[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/c0c6b5a8af09a2ac8b4393523d9b4833a3d5de2d78995d9b535394e726468a36

[melvin-bot]

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

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

Issue Analysis

Root Cause: Regression from Expensify/App#96897 ("migrate merge transaction v2"). That PR added a catch‑all redirect '/merge/*': '/search/merge/$1' in OldRoutes.ts. When you start a merge from the Inbox, the merge dynamic-route path collapses to a bare merge/... and this redirect forces it under the Search fullscreen navigator. So at merge time isSearchTopmostFullScreenRoute() returns true, and the post-merge branch in DynamicConfirmationPage.tsx:120-126 navigates to ROUTES.SEARCH_REPORT (the Spend tab) instead of dismissing back to the Inbox report.

Note isOnSearch itself is still correctly false from the Inbox — the bad tab comes entirely from isSearchTopmostFullScreenRoute() flipping to true.

Recommended Fix: As a deploy blocker, the safest resolution is a full revert of #96897. It touches shared navigation infrastructure (ROUTES/SCREENS/config/ModalStackNavigators + new dynamic-route helpers) and the failure mode spans multiple merge entry points that are hard to fully reason about under time pressure. A revert restores the prior standalone RHP merge routes where the modal opened over the true originating navigator.

If a revert is undesirable, the targeted fix is to stop pinning base-less merge URLs to Search: remove/replace the '/merge/*': '/search/merge/$1' redirect and ensure the merge dynamic route is always appended to a fullscreen-qualified base path matching the true origin (getMergeTransactionBasePath() in MergeTransaction.ts:87-94). This is riskier to get right quickly than a straight revert.

Investigation details & evidence chain

1. Post-merge branch (unchanged by the PR): DynamicConfirmationPage.tsx:120-126 — if ((isOnSearch || isSearchTopmostFullScreenRoute()) && searchReportIDToOpen) { dismissModal(); navigate(ROUTES.SEARCH_REPORT…) }. With isOnSearch === false from Inbox, only isSearchTopmostFullScreenRoute() returning true can trigger the Spend-tab navigation.

2. isOnSearch is correctly false from Inbox: MoneyRequestHeaderSecondaryActions.tsx:192 computes isReportInSearch = report is a Search screen — false for a workspace-chat expense — and passes it through setupMergeTransactionDataAndNavigate.

3. The dynamic-route migration mounts the merge steps as a suffix on the current path via createDynamicRoute(DYNAMIC_ROUTES.MERGE_TRANSACTION_*.getRoute(...), getMergeTransactionBasePath()) in MergeTransaction.ts. When the base collapses to a bare merge/..., getStateFromPath applies the OldRoutes redirect first (getMatchingNewRoute.ts), rewriting it to /search/merge/... → Search fullscreen navigator.

4. The PR's own test documents the intent: getMatchingNewRouteTest.ts:211-215 asserts getMatchingNewRoute('/merge/123') → '/search/merge/123'.

Confidence: Medium-High. The /merge/* → /search/merge/$1 redirect is the only PR-introduced change that flips isSearchTopmostFullScreenRoute() to true while isOnSearch stays false. The one step not verified at runtime is exactly when the Inbox base path collapses to a bare merge/... (vs. /r/:reportID/merge/...); a quick repro logging getTopmostFullScreenRoute()?.name at merge time from the Inbox would fully close the loop.

Alternative explanations considered: isOnSearch being wrongly set (ruled out — it's derived from the origin screen and is false from Inbox); the mergeExpenses logic itself changing (ruled out — that function was not modified by the PR).

---

Next Steps for Contributor+ team:
To accept: @MelvinBot implement [this](https://github.com/Expensify/App/blob/4c66847d8cfcd9f0f9632a7950d3386f51c877e4/src/libs/Navigation/linkingConfig/OldRoutes.ts#L68) to create a draft PR.
To refine: @MelvinBot <your feedback>
To reject: Explain why you are rejecting Melvin's proposal.

[MelvinBot]

🔍 Investigation Summary

Classification: Frontend bug
Causing PR: #96897 - "83847 migrate merge transaction v2" by @huult (High confidence)
Related Issues: None

Recommendation: REVERT

The regression is confirmed to originate entirely in this App PR's navigation migration, and it touches shared navigation infrastructure (OldRoutes redirects + new dynamic-route helpers) whose failure mode spans multiple merge entry points — a straight revert is the safest way to unblock the deploy. A targeted fix (below) is viable if a revert is undesirable, but it is riskier to land quickly.

Assigned: @huult (PR author), @suneox and @mjasikowski (approving reviewers) from the causing PR
Labels: No changes. DeployBlockerCash is kept (App deploy is correctly blocked by a frontend regression). No DeployBlocker label is present, so nothing to remove.

📋 Detailed Analysis

Evidence

• The bug reproduces on staging only, not production, and PR 83847 migrate merge transaction v2 #96897 is item Open room scrolled to bottom #77 on the current Deploy Checklist #97134 (2026-07-27) — it just reached staging in the same release (v9.4.45-0) where the blocker appeared.
• The PR migrated the merge-transaction routes from standalone RHP modal routes to dynamic-route suffixes, and added the catch-all redirect '/merge/*': '/search/merge/$1' in OldRoutes.ts.
• The PR's own test documents the intent: getMatchingNewRouteTest.ts asserts getMatchingNewRoute('/merge/123') → '/search/merge/123'.

Verification

• Affected post-merge branch: DynamicConfirmationPage.tsx:119-126 — if ((isOnSearch || isSearchTopmostFullScreenRoute()) && searchReportIDToOpen) { dismissModal(); navigate(ROUTES.SEARCH_REPORT…) }.
• isOnSearch is correctly false from Inbox: computed as isReportInSearch at MoneyRequestHeaderSecondaryActions.tsx:192 (route.name === SEARCH_REPORT || SEARCH_MONEY_REQUEST_REPORT) — false for a workspace-chat expense opened from Inbox.
• So only isSearchTopmostFullScreenRoute() flipping to true can trigger the Spend-tab navigation — and that flip is caused by the merge RHP being mounted under the Search fullscreen navigator.
• The merge steps are navigated as dynamic suffixes via createDynamicRoute(DYNAMIC_ROUTES.MERGE_TRANSACTION_*.getRoute(...), getMergeTransactionBasePath()) in MergeTransaction.ts:114-161. The suffix is a bare merge/:transactionID (ROUTES.ts:1141-1188). When the base path from getMergeTransactionBasePath() (MergeTransaction.ts:87-94) collapses so the resulting path is a bare merge/..., getStateFromPath applies the OldRoutes redirect first, rewriting it to /search/merge/... → Search fullscreen navigator.

Root Cause

The catch-all '/merge/*' → '/search/merge/$1' redirect unconditionally pins any base-less merge URL under the Search fullscreen navigator. Starting a merge from Inbox produces such a base-less merge/... path, so the merge RHP is mounted under Search rather than the true originating (Inbox) navigator. At merge completion, isSearchTopmostFullScreenRoute() returns true (while isOnSearch stays correctly false), so DynamicConfirmationPage takes the search branch and navigates to ROUTES.SEARCH_REPORT — the Spend tab — instead of dismissing back to Inbox.

Targeted fix (if not reverting): stop pinning base-less merge URLs to Search — remove/replace the '/merge/*': '/search/merge/$1' redirect and ensure the merge dynamic route is always appended to a fullscreen-qualified base path matching the true origin via getMergeTransactionBasePath().

Alternatives considered & ruled out: isOnSearch being wrongly set (it is derived from the origin screen and is false from Inbox); a change to the mergeExpenses/mergeTransactionRequest logic (not modified by this PR).

[huult]

Checking