[Due for payment 2026-08-17] Expense - Splits are highlighted after splitting on Spend and opening report on Inbox

[applause-bot]

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: 9.4.15-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: #92506
Email or phone of affected tester (no customers): sjdoisnjdodsnjoi@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. Go to Spend > Expenses.
5. Select one of the expenses via checkbox.
6. Click dropdown button > Split > Save.
7. Go back to Inbox.
8. Open the expense report.

Expected Result:

Splits should only be highlighted on where the expense was split, which is Spend > Expenses.

Actual Result:

Splits are highlighted after splitting on Spend and opening report 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

Bug7184848_1781804629525.2.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Nathan Lemma
Bug ID: 7184848

Issue Owner

Current Issue Owner: @mallenexpensify

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

[melvin-bot]

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

[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

Regression from #92506 (this issue's linked PR). The PR registered split transactions for highlighting before the navigation branch, so the registration also runs on the Spend/Search path — where the report is never opened, leaving the highlight flags stranded until the report is opened later from Inbox.

What is the root cause of that problem?

In updateSplitTransactionsFromSplitExpensesFlow, PR #92506 added a loop that calls addPendingNewTransactionIDs(targetReportID, …) for each new split. This loop runs before the navigation branch at SplitTransactionUpdate.ts:1911.

addPendingNewTransactionIDs persists {pendingNewTransactionIDs: {[id]: true}} into the report's REPORT_METADATA (PendingNewTransactions.ts:18). These flags are only consumed — and only cleared — when the expense report's MoneyRequestReportActionsList mounts and useNewTransactions runs (MoneyRequestReportActionsList.tsx:126-129, useNewTransactions.ts:39-41).

When the user splits from Spend > Expenses (isSearchPageTopmostFullScreenRoute), the flow navigates back via navigateBackToLastSuperWideRHPScreen and returns — the expense report is never opened. So the flags are written but never read/cleared. They sit in REPORT_METADATA until the user later opens that report from Inbox, at which point the list mounts and incorrectly highlights the (no longer new) split rows.

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

Only register the pending-new transaction IDs on the path that actually opens the expense report. The Spend/Search-page early-return branch (and the !params.transactionReport?.parentReportID case that shares it) should not pollute the report's metadata.

Practically: guard the registration loop with !isSearchPageTopmostFullScreenRoute && !!params.transactionReport?.parentReportID, or move the loop below the if (isSearchPageTopmostFullScreenRoute || !params.transactionReport?.parentReportID) { … return; } branch so it runs only for the dismissModalWithReport path. Splitting from within the report keeps working because that path mounts the report and clears the flags as designed.

Why the Spend page still highlights correctly + verification notes

• The issue's Expected Result confirms the Spend > Expenses highlight is the desired behavior and is unaffected — that page does not rely on REPORT_METADATA.pendingNewTransactionIDs (the only reader is MoneyRequestReportActionsList for the routed report). So scoping the registration away from the Search path does not remove any wanted highlight there.
• Reproducible in staging: Yes / production: No, consistent with a regression from PR Fix: Highlight split expenses after splitting an existing expense #92506 which is in this deploy.
• The clear path (useNewTransactions.ts) only fires after the list mounts with matching transactions, confirming nothing clears the flags while the user stays on the Search page.
• Confidence: High — code-traced end to end; matches all reported symptoms and the staging-only reproduction.

---

Next Steps for Contributor+ team:
To accept: @MelvinBot implement [this](https://github.com/Expensify/App/issues/93967) to create a draft PR.
To refine: @MelvinBot <your feedback>
To reject: Explain why you are rejecting Melvin's proposal.

[mountiny]

cc @aswin-s

This sounds minor but the authors should follow up