Search - Last created expense appears in search results

[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.60-0
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from BrowserStack: https://test-management.browserstack.com/projects/2219752/folder/54000925/test-cases/41237511?q=4115
Email or phone of affected tester (no customers): -
Issue reported by: Applause Internal Team
Bug source: Regression TC Execution
Device used: Windows 11 / Chrome
App Component: Other

Action Performed:

Precondition: have several expenses (you can create them in self-DM chat).

1. Create new expense with unique Merchant
2. Go to Spend > Expenses tab
3. Click on Search icon and enter Merchant of expense from step 1
4. Press Enter (or click on suggestion)
5. Open Search field again > clear search input
6. Enter Merchant of any other expense
7. Press Enter (or click on suggestion)

Expected Result:

Search result will show only expense with searched Merchant

Actual Result:

Search result show expense with searched Merchant and last created expense (from step 1)

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7242149_1787649408615.bandicam_2026-08-25_12-08-29-151.1.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Svetlana Lazutkina
Bug ID: 7242149

Issue Owner

Current Issue Owner: @gijoe0295

[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/9cb358846cd7b5389d30fb0ba82cd0b43d4eab25073ae2437fc0c84c6498dc9b

[MelvinBot]

Proposal

What is the root cause of that problem?

The lingering row is the optimistically-tracked "last created expense" being force-injected into whatever Search query is currently open, with no check that the expense matches the active query's filters (merchant, etc.).

When you create an expense, its write is deferred through a single app-global channel (DEFERRED_LAYOUT_WRITE_KEYS.SEARCH). The Search results layer reads that global watch key and unconditionally adds the referenced transaction to the current search's data:

• useOptimisticSearchTracking.ts:146-185 — injects the optimistic transaction gated only on transaction-search-type + non-empty watch key + not-yet-cleared. There is no predicate that the transaction matches the current query (merchant Y).
• useOptimisticSearchTracking.ts:45-58 — the watch key comes from a query-agnostic global channel, not from the search hash.
• deferredLayoutWrite.ts:207-213 — getOptimisticWatchKey falls back to flushedWatchKeys, so the key survives after the write flushes and is only cleared when a new deferred write reserves the channel.

So after you create an expense and then run two different merchant searches, the created expense is re-injected into the second (non-matching) search. The results component remounts on query change (key={queryJSON.hash} in SearchPageWide.tsx:128), but remounting only resets a per-mount ref — it re-reads the same global key and re-injects the same stale transaction. The guard that would clear tracking is short-circuited because there's no pending write on the remount (useOptimisticSearchTracking.ts:103-117).

This is purely client-side optimistic injection — not a snapshot MERGE bleed: different merchants hash to different SNAPSHOT_<hash> keys, so the backend results are correctly separate.

Data flow & why other explanations were ruled out

1. Create expense → write deferred via SEARCH channel; its transaction key stored as the global optimisticWatchKey.
2. Search merchant X (hash A) → results mount; the created expense is injected into query A.
3. Clear input, search merchant Y (hash B) → SearchWithNavigationDeferredMount remounts (key changes).
4. New mount reads the same global watch key (still resolvable via the channel or the flushedWatchKeys fallback) and injects the same transaction into query B — with no merchant match.
5. hasPendingWriteOnMount is false on this remount, so clearOptimisticTracking() is never called and the stale row persists.

Ruled out: server SET-vs-MERGE snapshot bleed — different merchants produce different primaryHash/SNAPSHOT_<hash> keys, so backend snapshots don't overlap. isTransactionSearchType is true for EXPENSE/INVOICE (SearchUIUtils.ts:4824-4826), confirming the Expenses-tab flow hits this path.

Note: I attempted to reproduce this on web, but the test session hit an infra issue (blank page) and couldn't run — so this analysis is based on code tracing, not a runtime repro.

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

Stop injecting the optimistic transaction into a query it doesn't belong to. Any one (ideally the first) of:

1. Gate the injection on a query match in useOptimisticSearchTracking.ts:146-185: only inject the optimistic transaction when it actually satisfies the active queryJSON filters (or only into the search hash that originated the create).
2. Scope the watch key to the originating query hash rather than a single global channel, so a different-hash search doesn't resolve it.
3. Clear flushedWatchKeys[SEARCH] once consumed in deferredLayoutWrite.ts:207-213, and/or invalidate optimisticWatchKey on query-hash change so the stale key can't be reused.

Option 1 is the most direct fix for the reported symptom; option 2/3 hardens the underlying global-state reuse.

What alternative solutions did you explore? (Optional)

Possibly related: Expensify/App#96982 — a Spend-Expense remaining in the description-filter results after its description changes. It may share this stale-injection mechanism; worth checking together.

---

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

---

view run

[melvin-bot]

Triggered auto assignment to Contributor-plus team member for initial proposal review - @gijoe0295 (External)

[melvin-bot]

Unable to auto-create job on Upwork. The BZ team member should create it manually for this issue.

[melvin-bot]

@gijoe0295 Uh oh! This issue is overdue by 2 days. Don't forget to update your issues!

[gijoe0295]

@MelvinBot I can no longer reproduce the bug. Can you check if it was already fixed somewhere based on your root cause analysis?

[MelvinBot]

⚠️ Claude's API is currently overloaded (HTTP 529). This is a temporary issue on Anthropic's side. Try again in a few minutes, or check status.anthropic.com.

Run details

[mukhrr]

@gijoe0295 I am still able to reproduce this consistently

tasker-video-99450-bug.mp4