[Due for payment 2026-07-17] Original expense briefly appears after splitting an expense

[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.32-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/63957099/folder/13176791/41237175/1554721639?sort=%2Bidentifier
Email or phone of affected tester (no customers): applausetester+abr2d6dt@applause.expensifail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Web
App Component: Money Requests

Action Performed:

1. Go to staging.new.expensify.com
2. Open a workspace chat.
3. Create an expense.
4. Split the created expense.
5. Observe the expense list.

Expected Result:

After splitting an expense, the original expense should be removed immediately and should not briefly appear in the list.

Actual Result:

The original expense briefly appears for a moment after splitting, then gets removed from the list.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7203791_1783601752934.2026-07-09_14-44-22.mp4

View all open jobs on GitHub

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

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

[melvin-bot]

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

[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

🤖 Automated analysis — High confidence. This is a deploy-blocker regression traced to a recently merged PR.

What is the root cause of that problem?

The split logic is correct: it optimistically hides the original expense by moving its reportID to SPLIT_REPORT_ID (-2) while adding the child splits to the report — see SplitTransactionUpdate.ts:1475-1490. The end state is right; the bug is a timing flicker.

The workspace-chat expense list is rendered from the REPORT_TRANSACTIONS_AND_VIOLATIONS OnyxDerived value (via useReportTransactionsCollection.ts:20), which buckets transactions by reportID.

Expensify/App#95287 — "Coalesce OnyxDerived recomputations via macrotask scheduling" (merged 2026-07-08, one day before this report; author fabioh8010) — changed that derived value from recomputing synchronously to a deferred macrotask (OnyxDerived/index.ts:195-200, scheduleMacrotask.ts). The raw TRANSACTION Onyx writes from the split now broadcast to the UI before the derived recompute runs, so the list renders for one frame with the child splits already added but the original not yet removed. One macrotask later the recompute lands and the original disappears — exactly the reported "briefly appears, then removed."

This matches every symptom: web-only (the MessageChannel fast-path is web-only), staging-only (PR not yet in production), and self-correcting after a beat.

Investigation details & evidence

• List source: MoneyRequestReportView → useReportTransactionsCollection(reportID) → reads DERIVED.REPORT_TRANSACTIONS_AND_VIOLATIONS, selecting [reportID].transactions.
• Correct end state: reportTransactionsAndViolations.ts:57-109 tracks each transaction's previous reportID and deletes it from the old bucket before adding to the new one — so once the recompute runs the original is gone. The defect is purely when it runs.
• Optimistic hide is immediate, not server-dependent: the original's reportID flip to -2 uses Onyx.SET with the comment "to prevent UI inconsistency" (SplitTransactionUpdate.ts:1477). No backend round-trip is involved in the flicker.
• Alternatives ruled out: Search-snapshot path (useOptimisticSearchTracking) is correctly maintained by the split action but is not the data source for the workspace-chat list, so it isn't the cause here. The split's own optimistic data is not the problem — reverting the derived-value timing change makes the flicker disappear.
• Timing: #95287 merged 2026-07-08 16:51 UTC; issue filed 2026-07-09 on staging 9.4.32-0; not reproducible in production.

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

Because this is a deploy blocker, the safest unblock is to revert / CP-revert Expensify/App#95287 (cc fabioh8010), which changed global derived-value timing.

If the coalescing optimization should be kept, the targeted fix is to let list-critical derived values (at minimum reportTransactionsAndViolations) recompute synchronously rather than on a deferred macrotask — e.g. a per-config synchronous/deferred flag consumed at the scheduling point in OnyxDerived/index.ts:195-200, keeping macrotask coalescing only for non-visual derived values.

What alternative solutions did you explore? (Optional)

Batching the original-removal and child-add writes into a single Onyx update so the coalesced recompute never observes an intermediate state — more fragile, since recompute timing is now decoupled from the write regardless.

---

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