Reports - Expense row is not highlighted after creating expense

[jponikarchuk]

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

Action Performed:

1. Go to staging.new.expensify.com
2. Go to Reports > Expenses.
3. Submit an expense from FAB.
4. Submit another expense from FAB.

Expected Result:

Expense row will be highlighted each time after creating expense on Reports.

Actual Result:

Expense row is only highlighted after creating expense on Reports for the first time.
The table flickers without highlighting the expense row when creating another expense.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Video.mp4

View all open jobs on GitHub

[melvin-bot]

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

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

[OSBotify]

🔍 Investigation Summary

Classification: Frontend bug
Causing PR: #85629 - "Defer API.write during Search screen transition to reduce perceived latency" by @JakubKorytko (High confidence)
Related Issues: None

Recommendation: REVERT

PR #85629 introduced a deferred write mechanism to improve perceived performance when navigating to the Search screen after expense creation. However, the implementation has a bug when creating multiple expenses sequentially from the same Search screen.

Labels: Keeping DeployBlockerCash (frontend bug blocks App deploy). Removing DeployBlocker as this is a frontend-only issue.

📋 Detailed Analysis

Evidence

The bug is reproducible only on staging (where PR #85629 is deployed) and not in production. The symptoms match exactly what the PR changed:

• First expense: highlights correctly
• Second expense: table flickers without highlighting

PR #85629 was merged on 2026-03-25 at 18:42:49Z and is included in the 9.3.49-0 staging deploy.

Verification

The affected code is in src/components/Search/index.tsx and the expense creation flow in src/libs/actions/IOU/index.ts. PR #85629 modified both files extensively to add the deferred write mechanism.

Key files modified by PR #85629 that relate to the bug:

• src/components/Search/index.tsx - Added deferred write handling with refs that track state across renders
• src/libs/actions/IOU/index.ts - Wrapped API.write calls in registerDeferredWrite
• src/libs/deferredLayoutWrite.ts - New file implementing the deferral mechanism

Root Cause

The issue occurs when creating a second expense while the Search screen is already mounted and visible:

1. First expense (works correctly):

   • User submits expense from FAB
   • hasPendingWriteOnMountRef.current = true (line 430 of Search/index.tsx)
   • skipDeferralOnFocusRef.current = false (line 432)
   • Search screen mounts/focuses
   • Deferred write executes on layout
   • Row highlights correctly

2. Second expense (broken):

   • User submits second expense from FAB
   • Search component stays mounted (doesn't remount)
   • Refs keep their old values: hasPendingWriteOnMountRef.current = true, skipDeferralOnFocusRef.current = false
   • New deferred write is registered for the second transaction
   • When Search refocuses, useFocusEffect (lines 432-449) runs
   • Since skipDeferralOnFocusRef.current = false, it calls deferHeavySearchWork(true)
   • This sets shouldDeferHeavySearchWork = true, triggering skeleton display
   • Table flickers as content is replaced with skeleton
   • The highlighting mechanism gets confused by the unexpected skeleton state

The core problem is that refs are not reset between subsequent expense creations when the Search component remains mounted. The logic was designed assuming Search would remount for each expense, but in the sequential creation flow, it stays mounted.

Specifically:

• hasPendingWriteOnMountRef is only set once on mount (line 430), never updated
• skipDeferralOnFocusRef is only set once on mount (line 432), never reset
• When creating expense Fix spaces #2, these stale ref values cause incorrect behavior in the useFocusEffect hook

[MelvinBot]

Proposal

Please re-state the problem that we are trying to solve in this issue.

After creating the first expense from the FAB on Reports > Expenses, the new expense row is correctly highlighted. However, creating a second (or subsequent) expense causes the table to flicker without highlighting the new row. This is a regression from PR #85629 which introduced deferred API.write() during Search screen transitions.

What is the root cause of that problem?

PR #85629 added an optimistic tracking mechanism in src/components/Search/index.tsx to show a skeleton/placeholder while a deferred API.write() flushes during the Search screen transition. This tracking state is initialized via useRef only at mount time (lines 217-227):

• hasPendingWriteOnMountRef — captures whether a deferred write exists when the component mounts
• optimisticWatchKeyRef — captures the Onyx key to watch for the optimistic item
• optimisticTrackingCleanedUpRef — guards one-time cleanup of the tracking state

The Search component stays alive between expense creations via react-freeze (as noted in the code comment at line 1384). So when the user creates a second expense, the component does not remount — these refs retain stale values from the first creation.

Critically, optimisticTrackingCleanedUpRef is set to true during the first expense's lifecycle (line 233 in clearOptimisticTracking) and is never reset to false. This makes clearOptimisticTracking a permanent no-op, which means:

1. hasPendingWriteOnMountRef is stale → shouldShowRowSkeleton (line 464) is false → no skeleton buffer for the second expense
2. optimisticWatchKeyRef was cleared to undefined (line 235) → the optimistic item tracking effect (line 1221) early-returns → no stableSortedData re-injection
3. The deferred write does flush via useFocusEffect (line 1402), but without the skeleton → content transition, the data update causes an abrupt full re-render (the visible "flicker") that disrupts the highlight animation

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

In the useFocusEffect callback in src/components/Search/index.tsx (around line 1386), before flushing the deferred write, re-initialize the optimistic tracking state when a new deferred write is detected:

1. Check hasDeferredWrite(CONST.DEFERRED_LAYOUT_WRITE_KEYS.SEARCH) and getOptimisticWatchKey(...) on re-focus
2. If a pending deferred write exists, reset:
   • hasPendingWriteOnMountRef.current = true
   • optimisticWatchKeyRef.current to the new watch key
   • optimisticTrackingCleanedUpRef.current = false
   • cachedOptimisticItemRef.current = null
   • Set showPendingExpensePlaceholder(true) and shouldDeferHeavySearchWork(true) so the skeleton/placeholder displays
3. Then proceed with the existing flushDeferredWrite() call

This ensures the optimistic tracking lifecycle (skeleton → optimistic item → server-confirmed item with highlight) is properly re-initialized for each expense creation, regardless of whether the Search component remounts.

What alternative solutions did you explore? (Optional)

An alternative would be to force the Search component to fully remount between expense creations (e.g., by changing the key prop). However, this would defeat the purpose of react-freeze caching and the performance optimizations from PR #85629. Resetting the refs on re-focus is the minimal, targeted fix that preserves the existing architecture.

---

Next Steps for Contributor+ team: Reply with @MelvinBot implement this to create a draft PR, @MelvinBot <your feedback> to refine this analysis, or explain why you are rejecting Melvin's proposal.

[JakubKorytko]

Not a regression from deferred API call, dupe of #85640 that was a dupe of #85521, pre-existing.