Spend-The newly added expense highlights every time updating other expense

[mitarachim]

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: v9.3.62-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: #83127
Email or phone of affected tester (no customers): testpayment935@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Windows 11 pro /Chrome
App Component: Search

Action Performed:

1. Navigate to staging.new.expensify.com
2. Log in with new account
3. Create an expense in WS chat
4. Go to spend > create expense
5. Wait until the highlight goes off
6. Update merchant filed of the existing expense by delete all merchant name and substitute by other
7. Press enter in the keyboard

Expected Result:

The newly added expense should not highlighted

Actual Result:

The newly added expense highlighted every time when updating existing expense

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7137020_1776982832891.bandicam_2026-04-24_01-14-49-840.mp4

View all open jobs on GitHub

[melvin-bot]

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

[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: #83127 - "feat: Add inline editing for tables on desktop" by @mohammadjafarinejad (High confidence)
Related Issues: N/A

Recommendation: REVERT

PR #83127 introduced inline editing for transaction table cells and is the direct cause of the highlight regression. The fix requires changes to the App codebase, and the PR is large enough that a targeted fix may be preferable to a full revert — but reverting is the safest default to unblock the deploy.

Assigned: @mohammadjafarinejad (PR author), @ahmedGaber93 @puneetlath (approving reviewers) from highest-confidence causing PR only
Labels: DeployBlockerCash kept (frontend App PR is the cause); DeployBlocker is not present on this issue and no action is needed there.

📋 Detailed Analysis

Evidence

• The melvin-bot already assigned PR feat: Add inline editing for tables on desktop #83127 as the causing PR, consistent with the bug being introduced in this staging version.
• PR feat: Add inline editing for tables on desktop #83127 merged on 2026-04-21, shortly before this bug was reported on 2026-04-23 in staging version v9.3.62-0.
• The PR is listed in the StagingDeployCash deploy checklist for v9.3.62-0.
• The PR explicitly introduces TransactionListItem changes (src/components/Search/SearchList/ListItem/TransactionListItem.tsx) and the useTransactionInlineEdit hook, both of which are directly in the code path for the expense highlight behavior.
• The bug reproduces on staging only (not production), consistent with a newly merged PR being the cause.

Verification

Affected files:

• src/components/Search/SearchList/ListItem/TransactionListItem.tsx — where useAnimatedHighlightStyle with shouldAnimateInHighlight is applied.
• src/components/Search/SearchList/index.tsx — where newTransactionIDByItemKey is computed and wasRecentlyEditingCell / isEditingCell state is consumed.
• src/components/Table/EditableCell/EditingCellContext.tsx — new file introduced by this PR that tracks editing cell state.
• src/hooks/useTransactionInlineEdit.ts — new hook introduced by this PR.
• src/libs/actions/TransactionInlineEdit.ts — new action file introduced by this PR.

PR #83127 modifies all of these files (confirmed via gh pr view 83127 --json files).

Root Cause

When the user edits a transaction's merchant (or any inline-editable field), the updateMoneyRequestMerchant action is dispatched via TransactionInlineEdit.ts, which causes an optimistic Onyx update on the transaction record. This Onyx update is picked up by useSearchHighlightAndScroll — specifically the effect at line 79 that compares current transactions keys to previousTransactions keys. Even though the transaction ID itself does not change, the Onyx collection reference changes, which can cause hasTransactionsIDsChange to evaluate to true (because Object.keys(transactions) re-evaluates on every Onyx update).

When this happens, a new search is triggered. The resulting search response may return the same transaction IDs that were already present, but since previousSearchResults was just updated by the search triggered by the hook itself, the newTransactionIDs filter can identify the edited transaction as "new" (if triggeredByHookRef.current is true and the IDs aren't yet in highlightedIDs.current). This results in setNewSearchResultKeys being called with the updated transaction's key, causing shouldAnimateInHighlight to be set to true for the edited expense row — producing the unwanted highlight animation every time an expense field is edited.