[$250] Spend - First expense row flickers after switching from Inbox to Spend

[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.45-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/66508749/folder/13176730/41237111/1607929394?sort=-identifier
Email or phone of affected tester (no customers): sjdoijsdonjsdoijsiojnio@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 two expenses.
4. Go to Spend > Expenses.
5. Go to Inbox.
6. Go to Spend > Expenses.

Expected Result:

First expense row will not flicker after switching from Inbox to Spend.

Actual Result:

First expense row flickers after switching from Inbox to Spend.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7219143_1785182084419.6.mp4

View all open jobs on GitHub

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

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022082212781202898180
• Upwork Job ID: 2082212781202898180
• Last Price Increase: 2026-07-28

Issue Owner

Current Issue Owner: @yusufdeveloper2903

[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/1b316999ca99c78fa379430275670bbebd27169747f745314574044acd751d3e

[melvin-bot]

Triggered auto assignment to @marcochavezf (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

⚠️ Confidence: medium — this is a frontend timing/animation issue. The root cause below is well-supported by code, but the exact re-fire trigger should be confirmed with an in-browser trace before implementing.

What is the root cause of that problem?

The "flicker" is the new-expense highlight animation replaying on the first (newest) row when the Search screen re-renders on navigation back.

Expenses default-sort date desc, so the expense you just created is at index 0 — the first row. Two things combine to make only that row flash when you return from Inbox:

1. Search is not unmounted on web — it's suspended by react-freeze. Leaving to Inbox freezes the Search subtree; coming back thaws and re-renders it. This is why the bug is web-only (Chrome/Safari) and doesn't repro on native.
2. On refocus, the Search API is re-fired (Search/index.tsx:373-413), which pulses snapshot.search.isLoading true→false and replaces the snapshot data object. useSearchSnapshot re-runs its projection and re-stamps shouldAnimateInHighlight, and the top row re-renders/remounts while the highlight animation (useAnimatedHighlightStyle, gated on didScreenTransitionEnd) is eligible to replay.

The reason it's the first row specifically: in useSearchHighlightAndScroll.ts:309-317, the new-item handler returns early for index ≤ 0 without resetting triggeredByHookRef, so the highlight machinery is left "armed" only for the top row. Rows below index 0 get the reset; row 0 doesn't.

Supporting evidence & data flow

• Highlight flag stamped per-row: useSearchSnapshot.ts:325-342 (shouldAnimateInHighlight = isBaseKeyMatch || isAnyTransactionMatch).
• Wide (desktop-web) row consumes the flag without the mount latch the Narrow row has, so a remount with shouldHighlight=true replays a full opacity 0→1 fade: TransactionListItemWide.tsx:145-151 vs the latched TransactionListItemNarrow.tsx:86-108.
• isLoading optimistic/finally pulse on every refetch: Search.ts:692-748. The full-page skeleton is ruled out — isDataLoaded stays true on a warm refocus (index.tsx:338-343), so this is a per-row artifact, not a skeleton swap.

Flow: create expenses → top row highlighted once, but its reset is skipped (index 0) → navigate to Inbox (Search freezes) → navigate back (Search thaws + refetch replaces snapshot data) → top row re-renders while still "armed" → highlight fade replays → flicker.

This is staging-only / not in production, so it's a recent regression (v9.4.45-0). Git history was unavailable in this checkout — a bisect on useSearchHighlightAndScroll.ts, useSearchSnapshot.ts, and the freeze wrapper around the 9.4.45 window would pinpoint the introducing PR.

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

Primary (smallest, first-row-specific): in useSearchHighlightAndScroll.ts:309-317, also reset triggeredByHookRef.current = false in the indexOfNewItem <= 0 early-return branch, so the top row can't stay "armed" across an Inbox round-trip.

Defense-in-depth: give the Wide row the same mount-latch behavior as the Narrow row (or pass skipInitialFade once the highlight has already been consumed) in TransactionListItemWide.tsx:145-151, so a react-freeze thaw/remount never replays a stale highlight.

Before implementing, confirm the exact trigger with an in-browser trace (log shouldAnimateInHighlight flips in useSearchSnapshot and the enter effect in useAnimatedHighlightStyle while reproducing Inbox→Spend). This disambiguates "highlight replay" from "pure snapshot-churn remount," which changes which of the two fixes is sufficient.

What alternative solutions did you explore? (Optional)

Skipping/short-circuiting the focus-refetch when snapshot data is unchanged (avoids the row-identity churn entirely), or memoizing row identity so the first row doesn't remount on refocus. These are broader and riskier than the targeted reset above.

---

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

[MelvinBot]

🔍 Investigation Summary

Classification: Frontend bug
Causing PR: #95618 - "[Split #94595] Batch C - Remove useOnyx deps from Search" by @fabioh8010 (Medium confidence)
Related Issues: none

Recommendation: REVERT

Two staging-only Search-performance refactors landed on 2026-07-24 (this 9.4.45-0 window) and both perturb the exact re-render/snapshot machinery that gates the first-row highlight animation. #95618 is the more likely trigger because it removes the useOnyx dependency arrays from the transaction-row selectors, making their results recompute to new references on every render and amplifying the top row's re-render when Search thaws from react-freeze and refetches on refocus — replaying the highlight fade. Revert #95618 first and re-test; if the flicker persists, revert #96642 next.

Assigned: @fabioh8010 (PR author), @hoangzinh and @mountiny (approving reviewers) from the highest-confidence causing PR (#95618)
Labels: No change. DeployBlockerCash kept (this is a frontend bug that blocks the App deploy). DeployBlocker was not present, so nothing to remove. Never removing both / keeping the App blocker since an App PR caused it.

📋 Detailed Analysis

Evidence

The bug is web-only (Chrome/Safari, not native) and staging-only (not production) — a regression newly introduced in the 9.4.45-0 window. Web-only + "first row re-renders and the highlight fade replays" points at the interaction between the desktop-web react-freeze suspend/thaw on the Search screen and the per-row highlight (useAnimatedHighlightStyle, gated on item.shouldAnimateInHighlight).

I bisected via the GitHub API (local App checkout is a shallow clone). The production...staging compare shows exactly two staging-only PRs touching the Search highlight/snapshot/row path:

1. #95618 by @fabioh8010, merged 2026-07-24T17:00Z. Removes the useOnyx dependency arrays from Search row selectors, including in src/components/Search/SearchList/ListItem/TransactionListItem/index.tsx — the parent of the highlight-carrying TransactionListItemWide. Selectors like personalDetailsLoginSelector(...) and the inline parentReportAction selector build a fresh object each call; without the deps array their memoization is weakened, so they return new references and re-render the row more aggressively.

2. #96642 by @TMisiukiewicz (callstack), merged 2026-07-24T09:09Z. Modifies src/components/Search/hooks/useSearchSnapshot.ts (the hook that stamps shouldAnimateInHighlight per row) by gating reportAttributesDerivedValue out of the getSections deps for non-chat/task types. This changes when the snapshot data object / getSections recomputes on the expenses view, i.e. it alters row-identity churn on refocus. This is a memoization change and would generally reduce recomputes, so I rank it below [Split #94595] Batch C - Remove useOnyx deps from Search #95618.

I explicitly ruled out the two highlight PRs that first looked suspicious:

• fix: Reports - Highlight animation is visible on added expense after duplication #94670 ("Highlight animation is visible on added expense after duplication", @TaduJR) — its useNewTransactions.ts/Search/index.tsx changes are already in production, so it cannot be this staging-only regression.
• Standardize Expense Report and Expense header with predictable button placement and carousel counter #90403 — reverted, and unrelated (header/carousel).
• src/hooks/useSearchHighlightAndScroll.ts (the indexOfNewItem <= 0 early-return that doesn't reset triggeredByHookRef) has had no substantive change since May and is in production, so it is a latent contributor, not the regression source.

Verification

• Affected feature files that changed staging-only (from gh api repos/Expensify/App/compare/production...staging): src/components/Search/hooks/useSearchSnapshot.ts, src/components/Search/SearchList/ListItem/TransactionListItem/index.tsx, TransactionListItemNarrow.tsx.
• Confirmed [Split #94595] Batch C - Remove useOnyx deps from Search #95618 modifies TransactionListItem/index.tsx (removes the deps arg on submitterLogin and parentReportAction selectors) — this is the parent component of TransactionListItemWide, which owns the useAnimatedHighlightStyle fade gated on shouldHighlight: item?.shouldAnimateInHighlight.
• Confirmed Reduce getSections recompute cost during Pay flow #96642 modifies useSearchSnapshot.ts (the file that stamps shouldAnimateInHighlight).
• Both merge dates (2026-07-24) fall inside the 9.4.45-0 checklist (dated 2026-07-27) and both appear in the production...staging commit set.

Root Cause

The newest (index 0) expense row carries shouldAnimateInHighlight = true and, per the pre-existing useSearchHighlightAndScroll.ts index≤0 early-return, its highlight machinery is never reset. On desktop web the Search subtree is suspended by react-freeze when navigating to Inbox and thawed on return, and the Search API re-fires on refocus (replacing the snapshot). The staging-only selector-stability regression in #95618 (deps-array removal) makes the transaction row re-render with new selector references during that thaw+refetch, remounting TransactionListItemWide while shouldHighlight is still true — so the opacity 0→1 fade replays on the first row only, producing the flicker. #96642's getSections recompute-gating change is a plausible secondary contributor to the same row-identity churn.