[Due for payment 2026-09-15] Expense - Spend opens 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.73-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: https://test-management.browserstack.com/projects/2219752/test-runs/72690964/folder/52646791/55373587/1733024883?sort=-identifier
Email or phone of affected tester (no customers): jsdoijnodsdisojo@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. Create two expenses in workspace chat.
3. Open expense report.
4. Open any expense.
5. Click More > Merge.
6. Complete merging expenses.

Expected Result:

App will stay on Inbox after merging expenses on Inbox.

Actual Result:

Spend opens 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

Bug7253345_1788783000274.7.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Mita Rachim
Bug ID: 7253345

Issue Owner

Current Issue Owner: @thelullabyy

[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/1c391660e938d76b3fbd37a394b288a0c6bea0d22fdd1d9c97f9387601cfc4c4

[melvin-bot]

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

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

[melvin-bot]

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

[MelvinBot]

🔍 Investigation Summary

Classification: Frontend bug
Causing PR: #98949 - "Fix: prevent dynamic route crash when "action" query param exists in both base path and suffix" by @MelvinBot (Low-Medium confidence — candidate only, see below)
Related Issues: #97147 (same symptom, fixed by #97186), #89799

Recommendation: NEEDS INVESTIGATION

The bug is 100% client-side (post-merge navigation in the merge-expense flow), so DeployBlockerCash stays. I narrowed the symptom to a single branch in DynamicConfirmationPage, but I could not confirm which PR in this checklist flips its condition, and the leading candidate can't be safely reverted (its revert reintroduces a fatal iOS crash), so I'm not recommending a revert yet. One quick check by a repro-capable person (below) will pin it down immediately.

One-step disambiguation for whoever picks this up: reproduce on staging and read the browser URL on the merge confirmation step.

• URL contains ?isOnSearch=true → the param is leaking through the merge steps again (same class of bug as [Due for payment 2026-08-05] Expense - Merged expense opens on Spend after merging expenses on Inbox #97147); prime suspect is Fix: prevent dynamic route crash when "action" query param exists in both base path and suffix #98949.
• URL does not contain isOnSearch → then isSearchTopmostFullScreenRoute() is what's true, and the culprit is whatever changed the fullscreen navigator under the RHP in this release, not Fix: prevent dynamic route crash when "action" query param exists in both base path and suffix #98949.

Labels: No changes. DeployBlockerCash kept (App-side navigation bug, not reproducible in production). DeployBlocker was not present.

📋 Detailed Analysis

Evidence

Only one code path in the app can send you to the Spend tab after a merge — the "in search" branch of the merge confirmation page:

• DynamicConfirmationPage.tsx#L144: if ((isOnSearch || isSearchTopmostFullScreenRoute()) && searchReportIDToOpen) {
• DynamicConfirmationPage.tsx#L188-L191: Navigation.dismissModal() then Navigation.navigate(ROUTES.SEARCH_REPORT...) → search/view/:reportID, which opens the Spend tab.

The Inbox path is supposed to fall through to L195-L200 (dismissModalWithReport / dismissToSuperWideRHP), which keeps you on Inbox.

This is a repeat of #97147 ("Merged expense opens on Spend after merging expenses on Inbox"), whose root cause was isOnSearch being set/propagated incorrectly, fixed in #97186 by passing undefined from the list step.

Verification

Diffing production...staging (6c6afc3...f29363e), the merge-expense flow is almost entirely unchanged in this release:

File	Status in this release
src/pages/TransactionMerge/* (incl. DynamicConfirmationPage.tsx)	unchanged (identical blob on production and staging)
src/libs/Navigation/Navigation.ts, isSearchTopmostFullScreenRoute.ts	unchanged
src/libs/actions/MergeTransaction.ts	changed, but only the getDeleteTrackExpenseInformation(...) call signature in the self-DM branch — unrelated to navigation
src/components/MoneyRequestHeaderSecondaryActions.tsx	changed, but only to thread transactionThreadReportActions through — isReportInSearch logic untouched
src/libs/Navigation/helpers/dynamicRoutesUtils/getPathWithoutDynamicSuffix.ts + createDynamicRoute.ts	changed by #98949

So the only behavioural change inside this flow in this release is #98949, which is why it's the candidate.

The relevant merge-flow plumbing (all still on staging):

• MoneyRequestHeaderSecondaryActions.tsx#L216 — isReportInSearch is true whenever the screen is SEARCH_REPORT/SEARCH_MONEY_REQUEST_REPORT, and useNavigateToTransactionThread.ts#L97 opens an expense through ROUTES.SEARCH_REPORT even from Inbox — so the first merge step's URL can legitimately carry ?isOnSearch=true on Inbox.
• MoneyRequestHeaderSecondaryActions.tsx#L447 passes that flag into setupMergeTransactionDataAndNavigate.
• MergeTransactionsListContent.tsx#L175 deliberately passes undefined (this is the Fix merge navigation from Inbox opening Spend tab #97186 fix), so the flag must not survive into later steps.
• The only thing that could carry it forward is the base path, rebuilt by getMergeTransactionBasePath() and useDynamicBackPath, both of which call getPathWithoutDynamicSuffix — the function Fix: prevent dynamic route crash when "action" query param exists in both base path and suffix #98949 changed.
• DynamicDetailsReviewPage.tsx#L172 then forwards route.params.isOnSearch into the confirmation route.

Root Cause

Before #98949, getPathWithoutDynamicSuffix stripped all query params declared by the suffix being removed, so isOnSearch=true was dropped as soon as the flow moved off the merge/:transactionID step. After #98949 it keeps any param that a dynamic suffix matching the remaining base path could own (getPathWithoutDynamicSuffix.ts#L29-L44):

const paramsOwnedByBase = new Set(findAllMatchingDynamicSuffixes(pathWithoutDynamicSuffix).flatMap((match) => getDynamicRouteQueryParams(match.pattern) ?? []));
for (const key of paramsToStrip) {
    if (paramsOwnedByBase.has(key)) {
        continue;
    }
    params.delete(key);
}

All four merge steps declare queryParams: ['isOnSearch'] (ROUTES.ts#L1780-L1827), and the PR's own new test asserts exactly this behaviour for a stacked merge path — getPathWithoutDynamicSuffix('/r/123/merge/1/details/merge/2/confirmation?isOnSearch=true&reportID=5', ...) now keeps isOnSearch=true. So whenever the base path still ends in a merge suffix, isOnSearch=true now survives into the next step and reaches the confirmation page, re-opening the exact hole #97186 closed.

Caveat (why this is Low-Medium, not High): for the plain Inbox URL shape I traced by hand (search/view/<threadID>/merge/<txnID>?isOnSearch=true → base search/view/<threadID>), no dynamic suffix matches the base, so the param should still be stripped and the flow should behave as it does on production. I could not execute the matcher in this environment to check the real staging URLs, so the stacked-suffix case that makes this fire needs to be confirmed against a live repro — hence the URL check at the top.

Fix direction (not a plain revert): #98949 also made mergeQueryStrings non-fatal, which fixed a fatal iOS Hermes crash on the money-request Tag step; reverting the whole PR brings that crash back. A targeted roll-forward is better — either narrow the param preservation so it can't resurrect isOnSearch for sibling merge steps, or make the merge confirmation page stop trusting the URL flag and derive the context from the navigation state only.

cc @huult @suneox (fixed the identical #97147), @collectioneur @inimaga (reviewers of #98949) — any of you able to run the repro and check whether the confirmation-step URL carries isOnSearch=true?

[MelvinBot]

🤖 Web test steps verification results: ❌ fail

Confirmed reproducible on main (dev web), not just staging. I created two expenses in a workspace chat from the Inbox, opened the expense report, ran More > Merge, and completed the merge — the app immediately switched the active tab from Inbox to Spend and swapped the LHN to the Spend "Expense reports" list. This is the same class of regression as #97147.

Step	Status
Two expenses exist in the workspace chat expense report, reachable from Inbox Inbox workspace chat shows "Expense Report 2026-09-07" with 2 expenses — Merge Test Merchant A ($12.34) and Merge Test Merchant B ($12.34), total $24.68.	✅
The "Merge" option appears under the More menu on an expense opened from Inbox Opened "Merge Test Merchant A" via Inbox > workspace chat > Expense Report 2026-09-07, clicked More; dropdown listed Hold, Split, Merge, Duplicate expense, Move to report, View details, Delete.	✅
After completing the merge, the app stays in the Inbox and does NOT navigate to Spend After clicking "Merge expenses", the nav rail's Spend icon became active (green/bold) and the LHN switched to the Spend "Expense reports > Expenses" list; Inbox reverted to inactive grey. Before the merge, Inbox was active.	❌

---

How this narrows the investigation

This confirms the analysis in my earlier comment: the only branch that can open Spend after a merge is the "in search" branch at DynamicConfirmationPage.tsx:144, which navigates to ROUTES.SEARCH_REPORT at L188-L191 instead of falling through to the Inbox path at L195-L200.

The disambiguating check I asked for — whether the confirmation-step URL carries isOnSearch=true — could not be captured in this environment: the headless browser used for automated testing exposes no address bar and no way to read window.location.href. Whoever picks this up should run the repro locally with devtools open; that one URL read distinguishes the two candidate causes:

• URL contains ?isOnSearch=true → the param is leaking through the merge steps again (same class as [Due for payment 2026-08-05] Expense - Merged expense opens on Spend after merging expenses on Inbox #97147); prime suspect is Fix: prevent dynamic route crash when "action" query param exists in both base path and suffix #98949.
• URL has no isOnSearch → isSearchTopmostFullScreenRoute() is what's true, and the culprit is whatever changed the fullscreen navigator under the RHP this release.

Recommendation unchanged: needs a human to pin the PR. Do not blanket-revert #98949 — it also fixed a fatal iOS Hermes crash on the money-request Tag step. A targeted roll-forward is safer: either stop the confirmation page trusting the URL flag and derive search context from navigation state, or narrow the param preservation in getPathWithoutDynamicSuffix.ts:29-44 so sibling merge steps can't resurrect isOnSearch.

cc huult suneox (fixed the identical #97147)

---

view run · no recording available

[mountiny]

Reverted the pr