[$250] Spend - After splitting an expense on "Spend", created splits are not highlighted.

[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.44-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: #90455
Email or phone of affected tester (no customers): ibellicotest+2766@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Motorola MotoG60 / Android 12 (Hybrid app) - Windows 11 / Chrome
App Component: Search

Action Performed:

Prerequisite: Account has at least one workspace.

1. Open the staging.new.expensify.com website.
2. Create a manual expense and submit it to a workspace chat.
3. Navigate to "Spend" > "Expenses"
4. Select the just created expense.
5. Click on dropdown menu > "Split" > Save splits.
6. Note that splits are not displayed highlighted after appearing.

Expected Result:

After splitting an expense while on "Spend", both new splits should be displayed highlighted.

Actual Result:

After splitting an expense while on "Spend", new created splits are not displayed highlighted.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7215931_1784849074907.Split_Light.mp4

View all open jobs on GitHub

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

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022080660054647762546
• Upwork Job ID: 2080660054647762546
• Last Price Increase: 2026-07-24

Issue Owner

Current Issue Owner: @brunovjk

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

[melvin-bot]

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

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

[lanitochka17]

Video production:

Recording.6077.mp4

[MelvinBot]

Proposal

⚠️ Medium confidence. The highlight mechanism and the gap below are confirmed from code, but I could not runtime-verify the exact trigger nor bisect the introducing PR (this analysis mirror has squashed history). Treat the fix as the robust path; see "Next steps" for verification.

First, a likely mis-assignment: the deploy-blocker was auto-assigned off PR Expensify/App#90455, but that PR is a POLICY_TAGS useOnyx refactor of splitBill/createDistanceRequest. It does not touch the split-existing-expense flow (SplitTransactionUpdate.ts) or the search-highlight hook, so it is almost certainly not the cause. Please don't burn time reverting it.

What is the root cause of that problem?

The "Spend" > "Expenses" list is the Search page, and it highlights new rows only through useSearchHighlightAndScroll. That hook has two highlight channels:

1. Auto-detect — compares the search snapshot before/after and highlights genuinely-new transaction IDs, but only when its own trigger effect set triggeredByHookRef + hasNewItemsRef first (useSearchHighlightAndScroll.ts:220-228).
2. Manual — an explicit "highlight these IDs" flag via mergeTransactionIdsHighlightOnSearchRoute, which bypasses that gate (line 221).

The split-an-existing-expense flow (updateSplitTransactions) registers the new split IDs on a completely different highlight channel — REPORT_METADATA.pendingNewTransactionIDs via addPendingNewTransactionIDs — which is consumed only by the report view (MoneyRequestReportActionsList) and the report preview, not the Search list. It never calls the Search page's manual highlight the way global-create does (NavigationHelpers.ts:26-31).

So on the Spend > Expenses list, split highlighting falls back entirely to the fragile auto-detect path. Because the splits are injected into the snapshot by an optimistic write (not by the hook's own re-search), the detect effect can run while triggeredByHookRef/hasNewItemsRef are still false (the trigger effect's isFocused || isSearchTopmostFullScreenRoute() guard isn't reliably satisfied during the RHP dismissal), and the split IDs get rejected. Something in the 9.4.44 window perturbed that timing enough to break it (it worked in production).

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

Make split-on-Search use the manual highlight channel — the same one global-create/track/send-invoice already use — instead of relying on auto-detect. In updateSplitTransactions, when the split originates from the Search page (isSearchPageTopmostFullScreenRoute), call mergeTransactionIdsHighlightOnSearchRoute(CONST.SEARCH.DATA_TYPES.EXPENSE, {[splitID]: true}) for each newly created split transaction ID (the same IDs already written into the search snapshot). This routes through the gate-bypassing path at useSearchHighlightAndScroll.ts:221 and is immune to the optimistic-write/focus-guard timing problem.

What alternative solutions did you explore? (Optional)

Details, alternatives, and related prior work

• Fix the auto-detect path instead — e.g. loosen the triggeredByHookRef && hasNewItemsRef gate for optimistically-injected snapshot IDs. Riskier: that gate exists to avoid re-highlighting stale items the backend returns on deletion (see the comment at useSearchHighlightAndScroll.ts:136-139), so touching it can regress other flows. The manual channel is the targeted fix.
• ID / count checks are NOT the cause: the split snapshot keys match the Onyx transaction keys, and the transaction count does increase, so the mismatch/count theories were ruled out.
• Why the existing addPendingNewTransactionIDs call doesn't help here: it only feeds useNewTransactions, consumed by MoneyRequestReportActionsList.tsx:147 and MoneyRequestReportPreview/index.tsx:140 — neither renders the flat Spend > Expenses list.

Related prior work (context, for whoever picks this up):

• Expensify/App#73740 — made both splits highlight on "Reports > Expenses" via the auto-detect Set. This is the behavior that regressed.
• Expensify/App#92506 — added the report-view addPendingNewTransactionIDs registration for splits.
• Expensify/App#88982 — added split children to the search snapshot optimistically (the write that decoupled splits from the hook's re-search).

---

Next Steps for Contributor+ team:
To accept: @MelvinBot implement [this](https://github.com/Expensify/App/issues/96915) to create a draft PR.
To refine: @MelvinBot <your feedback> — in particular, please bisect the 9.4.44 StagingDeployCash to confirm the introducing PR, and verify with a manual/Playwright repro of split-from-Spend.
To reject: Explain why you are rejecting Melvin's proposal.

[amyevans]

This isn't a regression from a staging PR, it's just a fragile timing-based flow. I also was able to reproduce the issue on prod fwiw. Demoting!