Android - Home - Both splits disappear from "Recently Added" after deleting one of them.

[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.18-0
Reproducible in staging?: Yes
Reproducible in production?: N/A - new feature, doesn't exist in prod
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #93451
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)
App Component: Money Requests

Action Performed:

Prerequisite: Account has at least one workspace.
Prerequisite 2: No expenses created yet.

1. Open the Expensify app.
2. Navigate to workspace chat.
3. Create a manual expense.
4. Open the expense report.
5. Tap on "More" > "Split" > "Save"
6. Navigate to "Home" > "Recently Added"
7. Open one of the splits.
8. Tap on header to open details page and delete the expense.
9. Once redirected to "Recently Added" again, note that after some seconds, both splits disappear.
10. Navigate to another section and return to "Home"
11. Note that remaining split reappears.

Expected Result:

After deleting one split, remaining one should still be visible on "Recently Added" section on "Home"

Actual Result:

After opening and deleting one split, remaining one also disappears from "Recently Added" section on "Home". Remaining split only reappears after navigating to a different section and returning to "Home".

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7189221_1782265381301.Remaining.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Julia Ponikarchuk
Bug ID: 7189221

[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/54535a172aa658b0efb95ed4ed2588ee557b41e2599108c3b9d9905603f308a5

[melvin-bot]

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

[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

What is the root cause of that problem?

The new Recently added Home slot (PR #93451) renders purely from the Search snapshot — it has no optimistic fallback of its own. The displayed list is built only from searchResults?.data in useRecentlyAddedData.ts:110-177, and it only re-fires its backend search() when isFocused / hash / isOffline change (:101-106) — not in response to a delete.

Deleting one of two splits is treated as a reverse-split operation, not a single-row delete (splitExpenses.length === 1 && originalChildTransactions.length > 0). Its optimistic update scans every snapshot that contains the split children — including the Recently added snapshot — and sets both child transaction keys to null, re-injecting only the reverted original transaction, and only if a revertedOriginalTransaction with a reportID is found in the already-built optimistic data (SplitTransactionUpdate.ts:1389-1399).

So after deleting one split: both children vanish from the snapshot → the pure-projection slot shows neither expense. The surviving expense only reappears once a fresh backend search() repopulates the snapshot, which reliably happens only on the next isFocused false→true cycle — i.e. navigating away and back. This explains all three symptoms: both disappear, after a delay, and only return after navigation.

Evidence & data flow

1. Both splits show in Recently added, sourced from SNAPSHOT_<hash>.data (hash = {type: expense, from: [accountID]}).
2. Deleting one split routes through updateSplitTransactions → reverse-split branch (SplitTransactionUpdate.ts:1344-1448). It iterates allSnapshots, and for any snapshot containing the children nulls both keys.
3. The reverted original is re-added only if revertedOriginalTransaction is found by scanning prior optimisticData (:1370-1373) — fragile, and even when present its row only survives the ownership filter at useRecentlyAddedData.ts:140-150 if its reportID resolves.
4. The slot never re-fires on the delete; the remaining expense returns only when focus-return triggers fireSearch() and the backend rebuilds the snapshot — i.e. after navigating to another section and back.

deleteMoneyRequest itself never writes to the SNAPSHOT collection, so this is specific to the split/reverse-split path interacting with the new pure-snapshot slot.

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

Make the Recently added slot resilient to optimistic snapshot gaps instead of blindly projecting raw snapshot data:

• Preferred: In useRecentlyAddedData, overlay the local transactions_ collection (already loaded as localTransactions) onto the snapshot results, so a reverted/surviving expense that exists locally still renders during the optimistic window, rather than depending solely on the snapshot.
• Or ensure the reverse-split optimistic update reliably re-injects the reverted original transaction into all affected snapshots (the revertedOriginalTransaction lookup at :1370-1373 can come back undefined), so the surviving expense never drops out.
• Or re-fire the slot's search() when the underlying transactions change (not only on focus), so the snapshot self-heals without requiring navigation.

Given this is a deploy blocker on a brand-new feature, the first option is the most contained, App-only fix.

What alternative solutions did you explore? (Optional)

Reverting PR #93451 removes the blocker entirely if a forward fix can't land in time, since the bug only exists because of the new slot.

---

Confidence: High on root cause (verified in code across the split-delete and snapshot paths); Medium on the exact fix — the PR author should confirm whether revertedOriginalTransaction is reliably found in this flow.

---

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