Spend - Original expense is briefly visible on expenses list after being splitted.

[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.56-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: #97475
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. Navigate to workspace chat.
3. Create a manual expense.
4. Navigate to "Spend" > "Expenses"
5. Select the just created expense.
6. Click on dropdown menu > "Split" > Save splits
7. Note that when splits appear, original expense is still visible and selected for some time.

Expected Result:

Original expense should automatically disappear from expenses list after being splitted.

Actual Result:

Original expense is still visible for some time and still selected after being splitted while on "Expenses" section on "Spend".

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7236865_1787111570931.Briefly_Split.mp4

View all open jobs on GitHub

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

Issue Owner

Current Issue Owner: @ZhenjaHorbach

[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/9b0f2b74f2465b63b9fec21a226292bc7baf466ed546ed9c474e6cdc76703ae5

[melvin-bot]

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

[melvin-bot]

@mountiny @dmkt9 you have been assigned to this deploy blocker because you reviewed the offending PR: #97475

[melvin-bot]

@ZhenjaHorbach you have been assigned to this deploy blocker because you authored the offending PR: #97475

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

🔍 Deploy Blocker Analysis

Auto-assigned PR #97475 is NOT the cause — do not revert it (High confidence). Its revert would drop the SelfDM/distance-unit fixes without touching this bug.

Root cause: The forward-split optimistic update only removes the original expense from snapshot_${currentSearchHash} and never touches the grouped search snapshots (activeGroupSearchHashes). Spend > Expenses is a grouped Search view, so its rows are rendered from a group-hash snapshot the removal code skips — the original stays visible (and selected) until the server-side Search refetch returns. This matches "still visible… for some time," "still selected," and "not reproducible in production" (the grouped Spend view is new on staging).

Recommendation: Fix forward with a targeted change (do not revert). In the forward-split branch of updateSplitTransactions, apply the original-removal + child-injection to every active snapshot hash (currentSearchHash ∪ activeGroupSearchHashes), mirroring what the reverse-split branch already does. Also clear the now-removed transaction from the selection.

Investigation details

Why #97475 is refuted (High confidence) — I read its full diff. It only:

• adds a distanceUnit field in two param-building spots of SplitTransactionUpdate.ts (via conflict-fix commit e1d11d0) — it does not touch snapshot-removal or searchContext plumbing;
• resolves distance rate/unit in SplitExpenseItems.ts;
• sets pendingAction: null in the Create-Report move-transaction flow (Transaction.ts);
• adds an isDeletedAction guard in TransactionPreviewUtils.ts;
• handles self-DM tracked-expense delete + hides splits on 1:1 "Add existing expense".

None affect whether the original expense is optimistically removed from a grouped Search list. The melvin auto-assignment fired only because #97475 was the tester's most recently merged split-related PR (heuristic) and the one checklist PR that touched SplitTransactionUpdate.ts at all.

Affected code path

• The bulk "Split" action opens the Split page with backTo = the current search?q=... route → SplitExpenses.ts:131-138.
• "Save splits" calls updateSplitTransactionsFromSplitExpensesFlow with searchContext: { currentSearchHash, activeGroupSearchHashes, … } → SplitExpensePage.tsx:404 (isSearchBackToRoute / activeGroupSearchHashes at L148-150).

The asymmetry in updateSplitTransactions:

• Reverse split (delete a split) builds snapshotKeysToUpdate from both currentSearchHash and every activeGroupSearchHashes, plus an all-snapshot scan → SplitTransactionUpdate.ts:1497-1510.
• Forward split (create splits) removes the original and injects children into only snapshot_${searchContext?.currentSearchHash} → SplitTransactionUpdate.ts:1795-1834 (original removal at L1807-1810). It never consults activeGroupSearchHashes. The all-snapshot scan at L1721-1794 only runs for self-DM splits, not this workspace-chat case.

getActiveGroupSearchHashes returns hashes only when the query is grouped → SearchUIUtils.ts:3292-3295. Spend > Expenses is grouped, so its visible rows live in a group-hash snapshot that the forward-split removal skips.

Confidence

• Refutation of Fix regressions from SelfDM splits flow #97475: High
• Root-cause mechanism (forward split omits activeGroupSearchHashes for the grouped Spend view): Medium-High
• Exact PR that introduced the grouped Spend/Expenses view surfacing this: Undetermined — it's a Search/"Spend" grouping PR in the current checklist, not a split PR. (GitHub blame endpoint was returning 502s and the local clone is shallow.) Whoever owns the grouped Spend > Expenses Search view should confirm.

---

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