[Due for payment 2026-09-15] Spend - Expenses are not shown in the table after splitting on group-by:from view

[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.64-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: #98012
Email or phone of affected tester (no customers): sdsiodjnosdjiodsj@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Mac 26.5 / Chrome
App Component: Search

Action Performed:

1. Go to staging.new.expensify.com
2. Go to workspace chat.
3. Create an expense.
4. Go to Spend > Expenses.
5. Open search router.
6. Type group-by:from and search.
7. Expand the group.
8. Select the expense via checkbox.
9. Click dropdown button > Split > Save.

Expected Result:

The split expenses will be shown in the table.

Actual Result:

The split expenses are not shown in the table.
The original expense changes to Unreported status.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7245570_1787954791657.2.mp4

View all open jobs on GitHub

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

Issue Owner

Current Issue Owner: @ikevin127

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

[melvin-bot]

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

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

[melvin-bot]

@rlinoz @ikevin127 @JakubKorytko you have been assigned to this deploy blocker because you reviewed the offending PR: #98012

[melvin-bot]

💬 A slack conversation has been started in #expensify-open-source

[MelvinBot]

🔍 Investigation Summary

Classification: Frontend bug
Causing PR: #98012 - "perf: defer the split-save API.write behind the destination layout" by @Abdukhamid000 (High confidence)
Related Issues: N/A

Recommendation: REVERT

#98012 turns the split-save API.write into a deferred writeWhenReady, which drops the read-after-write ordering that API.read/search() rely on (waitForWrites → SequentialQueue.waitForIdle), so the group-by refetch fires while the write queue is still empty and comes back with pre-split server data. The PR's own description states the INP benefit "is still not demonstrated", so there is no measured win to weigh against a correctness regression, and it reverts cleanly (one production file).

Assigned: @Abdukhamid000 (PR author), @rlinoz, @ikevin127, @JakubKorytko (approving reviewers) from the highest-confidence causing PR only
Labels: No changes. DeployBlockerCash is kept (an App PR caused it). DeployBlocker was never applied, so nothing to remove.

📋 Detailed Analysis

Evidence

• Staging-only, and version 9.4.64-0 matches the open checklist #99794. Of the 30 App PRs in that release, perf: defer the split-save API.write behind the destination layout #98012 is the only one that touches the split-save path (src/libs/actions/IOU/SplitTransactionUpdate.ts). I checked the file lists of every other PR in the release: the only other Search-adjacent ones are 83207: debounce autocomplete query and memoize search options #86925 (SearchAutocompleteList/SearchRouter), Update conciergeChat to remove Onyx.connect - 38 #99638 (SearchRouter), Fix Amount filter being multiplied by 100x when using the global search box #99313 (SearchPageInput) and Restrict report state transitions to archived policies only #98948 (SearchWriteActionsProvider/selectionBuilders/useSelectedTransactionsActions) — none of them touch how split results are written to or refetched for the search snapshot.
• perf: defer the split-save API.write behind the destination layout #98012's only production change is replacing three direct apiWrite(...) calls with a writeSplit helper that routes through writeWhenReady(command, parameters, onyxData, createTransitionBarrier('navigation')) whenever isFromSplitExpensesFlow is true — which is exactly the flag the Search "Split → Save" path passes.
• Merged 2026-08-28T14:36Z, on staging for 9.4.64-0; the bug was filed 2026-08-28T22:29Z against that build and does not reproduce on production, which does not yet have the PR.

Verification

Affected files (all permalinks at 9b655c4, which contains the merged PR):

• Offending change: src/libs/actions/IOU/SplitTransactionUpdate.ts#L1993-L2001 — the writeSplit fork added by perf: defer the split-save API.write behind the destination layout #98012.
• Call site the repro steps hit: SplitTransactionUpdate.ts#L2135-L2143 — when Search is the topmost full-screen route, updateSplitTransactions({..., isFromSplitExpensesFlow: true}) runs and then navigation goes back to Search.
• Ordering guarantee that is lost: src/libs/API/index.ts#L170-L175 and #L194-L196 — reads wait for the sequential queue to drain, with the comment "Responses from requests can overwrite the optimistic data inserted by write requests that use the same Onyx keys and haven't responded yet." search() does the same at src/libs/actions/Search.ts#L1303-L1307.
• Group-by-specific refetch: src/components/Search/SearchList/ListItem/GroupChildrenContent.tsx#L99-L109 — an expanded group refetches its children from the server every time the Search screen regains focus (i.e. the moment the split RHP is dismissed).
• Why the optimistic data can't paper over it in this view: the forward-split branch writes its optimistic snapshot entries only to SNAPSHOT_${searchContext.currentSearchHash}, the parent grouped query. The expanded group's rows live in a separate snapshot keyed by groupItem.transactionsQueryJSON.hash (GroupChildrenContent.tsx#L42); only the reverse-split branch consults searchContext.activeGroupSearchHashes.

Root Cause

Before #98012, pressing Save queued Transaction_Split on the sequential queue synchronously. Every subsequent Search refetch is a read, and reads block on waitForWrites() → SequentialQueue.waitForIdle(), so the group's refetch could not reach the server until the split had been persisted. The server therefore returned the split children and the table was correct.

After #98012, the write is held behind createTransitionBarrier('navigation') and is not queued until the back-navigation transition finishes. In the meantime the Search screen regains focus, the expanded group's refreshTransactions() fires, waitForWrites() sees an empty queue and resolves immediately, and the group query hits the server before the split exists there. The response repopulates the group's snapshot from pre-split state, so the newly created split rows never appear. The Transaction_Split write then lands, the backend moves the original transaction off the expense report, and the row the user is still looking at flips to Unreported — precisely the reported symptoms.

The group-by view is where this surfaces because it is the one view with a second, independently-keyed snapshot that is only ever filled by a server refetch; in the flat Expenses view the optimistic entries on currentSearchHash keep the table looking right no matter how the refetch races.

A targeted fix is possible (arm the barrier before navigation and gate the group refetch on the same barrier, or extend the forward-split optimistic snapshot update to activeGroupSearchHashes), but each of those is a new race to reason about under deploy-blocker time pressure, and the deferral has no demonstrated benefit yet. Reverting #98012 restores the ordering guarantee for every consumer at once.

💡 Suggested AI code review rule

This bug looks like a recurring, mechanically detectable pattern, so it may be worth a coding-standards rule so the AI reviewer catches the next one. Proposed for Expensify/App:

• Rule: PERF-19 Don't defer a write whose destination screen refetches the same data
• Condition: Flag a diff that converts an existing API.write(...) into writeWhenReady(...)/deferOrExecuteWrite(...) when the flow's destination screen refetches the same data from the server (search(...), any API.read command) on focus, navigation or an Onyx change. Deferral must be paired with a refetch gated on the same barrier, or with optimistic data covering every snapshot the destination actually reads.
• Why: Reads block on waitForWrites()/SequentialQueue.waitForIdle(), so a synchronous write orders the refetch after it. Deferring the write leaves the queue empty, the refetch reaches the server first, and its response repopulates state from pre-write data — silently showing stale results, as in this deploy blocker.
• Search pattern: in the diff, rg '^-.*\b(apiWrite|API\.write)\(' co-occurring with rg '^\+.*\b(writeWhenReady|deferOrExecuteWrite)\(' in the same file; then rg 'search\(\{|API\.read\(' across the destination screen/hook the flow navigates to.
• Offending code (❌):

  App/src/libs/actions/IOU/SplitTransactionUpdate.ts

  Lines 1993 to 2001 in 9b655c4

  	// optimisticData is applied synchronously, re-rendering the destination screen mid-transition.
  	// Defer the write until the transition ends, unless there is none to wait on.
  	const writeSplit = <TCommand extends WriteCommand>(command: TCommand, parameters: ApiRequestCommandParameters[TCommand]) => {
  	if (!isFromSplitExpensesFlow) {
  	apiWrite(command, parameters, onyxData);
  	return;
  	}
  	writeWhenReady(command, parameters, onyxData, createTransitionBarrier('navigation'));
  	};

• Fix (✅): the direct apiWrite(command, parameters, onyxData) calls this replaced — the "before" side of the diff at https://github.com/Expensify/App/pull/98012/files

The full rule file, with the ❌/✅ code inline in Expensify/App's coding-standards format, would go in Expensify/App itself. If it's worth adding, a maintainer can open it there as a draft PR.

---

view run