Duplicate Search Commands Fired When Filtering by Merchant

[m-natarajan]

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.90-0
Reproducible in staging?: Y
Reproducible in production?: Y
If this was caught during regression testing, add the test name, ID and link from BrowserStack:
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Expensify/Expensify Issue URL:
Issue reported by: @iwiznia
Slack conversation (hyperlinked to channel name): #Quality

Action Performed:

1. Navigate to Spend.
2. Open the Merchant filter.
3. Enter a merchant name/search term.
4. Monitor the network requests or command logs.
5. Observe that two Search commands are fired for the same search.

Expected Result:

Only the necessary Search command should be fired when performing a Merchant search.

Actual Result:

Two Search commands are fired for the same search. The requests are nearly identical, with the only observed difference being:
Request 1: includes shouldSaveRecentSearch: true
Request 2: does not include shouldSaveRecentSearch

Workaround:

Unknown

Platforms:

Select the officially supported platforms where the issue was reproduced:

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

Screenshots/Videos

Recording.3546.mp4

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @cretadn22

[iwiznia]

I think this was introduced here cc @elirangoshen @marufsharifi @JS00001

[MelvinBot]

Proposal

What is the root cause of that problem?

Two different places own "fetch this query", and the loading skeleton guarantees they can never overlap — so the in-flight dedupe cannot collapse them.

1. Page-level fetch — src/hooks/useSearchPageSetup.ts:99 fires search() when the q param changes, but only if the snapshot isn't already loaded (:92-94).
2. Component-level fetch — src/components/Search/index.tsx:477-484 fires search() again on every mount of Search. It has no "this hash is already loaded" guard.

The only duplicate protection is a time-window map keyed on hash_offset in src/libs/actions/Search.ts:1200-1231, and its entry is deleted the moment the request settles (:1330-1332).

That window is always missed, because Search is not even mounted while request #1 is in flight — SearchPageWide.tsx:130-144 renders SearchLoadingSkeleton instead. Search can only mount after the response lands, and by then the dedupe entry is gone. So it fires request #2 with the same hash and offset.

Why Merchant is the reliable repro: nothing here is merchant-specific. A free-text merchant term always produces a brand-new (cold) query hash, which is exactly the case where the page-level fetch does not early-return. Re-applying a filter you already used this session is a warm hash, the page-level fetch skips, and you correctly get one Search.

Full evidence chain and line references

The filter itself is innocent. Both entry points fire exactly one navigation. The filter-bar pill goes TextFilterPopup.tsx:37-43 → useUpdateFilterQuery.tsx:42-61, which calls a single Navigation.setParams({q}). No debounce, no second navigation. The advanced-filters route (TextInputFilterContent.tsx:70-83) converges on the same hook. merchant is a text filter key (SearchAdvancedFiltersForm.ts:24-25).

Step by step:

1. Apply merchant → new hash → one Navigation.setParams.
2. snapshot_<newHash> does not exist, so searchResults is undefined (SearchPage.tsx:79-87) and shouldShowLoadingSkeleton is true (useSearchLoadingState.ts:27).
3. The skeleton renders and Search is unmounted. Note key={queryJSON.hash} at SearchPageWide.tsx:134, so every query change destroys and recreates the subtree.
4. Only the page-level effect runs → request Some initial fixes and code style updates #1, carrying shouldSaveRecentSearch: true (Search.ts:1241). Its optimistic data writes only search.isLoading/state, never data (Search.ts:798-810), so the skeleton stays up for the whole round trip.
5. Response lands → data present, isLoading: false → skeleton hides → Search mounts a frame later via NavigationDeferredMount.tsx:41-49.
6. The mount effect runs with isLoading === false and no loaded-data guard, falling through to handleSearch → request Fix spaces #2. The dedupe map no longer holds hash_0.

The two payloads are identical in hash, offset, searchKey and shouldCalculateTotals. The only difference is shouldSaveRecentSearch: true on #1 and absent on #2. This is a true duplicate, not two requests by design.

Ruled out:

• Typeahead. Autocomplete uses SearchForReports / SearchForUsers, not Search.
• Per-keystroke requests. The Merchant popup is a plain text input with an Apply button (TextFilterPopup.tsx:56-66).
• A totals/chart second request. Both calls resolve shouldCalculateTotals identically at offset 0.
• StrictMode double-invoke. USE_REACT_STRICT_MODE_IN_DEV: false (CONFIG.ts:143), and the issue reproduces in staging and production.
• A 9.4.90 regression. The page-level fetch and its guard landed 2026-04-27, the deferred mount 2026-05-27. The only Search commits between the 9.4.89 and 9.4.90 staging tags touch error views. This is a long-standing interaction, not a new break.

There may actually be a third request. Once #2 is in flight, isSnapshotSearchLoading / isInitialSearchPending flip, the page-level effect re-runs, and the :92-94 early return is bypassed. Because only the page-level caller sets shouldSaveRecentSearch, that collision hits needsSaveRecentSearchUpgrade and queues pendingUpgradeRequest (Search.ts:1209-1226), firing a third identical request after #2 resolves. Worth counting in the network log.

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

Give the query-change fetch a single owner. The mount fetch in Search exists for a real reason — refreshing when you navigate back to Spend with a cached snapshot — so it should not be deleted outright, just made to skip the hash the page already requested.

useSearchPageSetup already tracks exactly what's needed: requestedHashesRef at useSearchPageSetup.ts:60, populated at :97 right before it fires.

1. Expose that requested-hash set through the Search context as a one-shot token (read it once, then clear it).
2. In the effect at src/components/Search/index.tsx:427, skip only the first run for a hash the page already fetched, when the resulting snapshot is loaded and its offset matches. Every other branch — reconnect refresh, pagination, error retry, all-matching totals — stays untouched.

Separately worth fixing: the shouldSaveRecentSearch asymmetry between the two callers (Search.ts:1206-1228). Because only one caller sets the flag, any genuine collision between them is converted from a clean dedupe into a queued extra round trip.

What alternative solutions did you explore? (Optional)

• Move the warm refresh into useSearchPageSetup and delete the mount fetch from Search entirely — narrow the :92-94 early return to "skip only while a request for this hash is in flight". Cleaner end state with one owner, but a larger blast radius across pagination and reconnect paths.
• Add a "recently completed" TTL to the dedupe map. Rejected: it would also swallow legitimate post-action refreshes routed through SearchRefreshUtils.ts:19.
• Add a blanket isDataLoaded guard to the mount effect. Rejected: it would kill the tab-revisit refresh, which existing tests cover as "Mount refresh" (tests/ui/SearchPageTest.tsx:450).

Confidence, and what I could not verify

High confidence on the mechanism. Two independent investigations converged on the same code path, and I verified every line reference above against 4305362.

No runtime confirmation. I could not reproduce this live — the test session's page rendered blank (zero snapshot nodes, no captured network entries), so I never reached the Spend page. The analysis is entirely code-derived.

Two ways to confirm quickly from a network log:

• Two (or three) Search commands with the same hash within a few hundred ms of one filter application. The page-level one carries "shouldSaveRecentSearch":true in its jsonQuery; the component-level one does not. That identifies which owner sent which, and in what order.
• The [Search] Showing skeleton log from src/components/Search/index.tsx:410-417, timed against the two Search commands, confirms Search only mounted after the first response.

Open questions: whether the reporter saw 2 or 3 requests (the code predicts up to 3), and whether native/mWeb are affected. SearchPageNarrow has the same skeleton, key, and deferred-mount structure (SearchPageNarrow/index.tsx:347), so I expect yes, but I did not trace its static-rendering branch.

Related issues

My scan turned up no duplicate of this report. Possibly related, both touching Search request behaviour rather than this duplication:

• Infinite loading when filter reports which has more than 50 expenses in them (Expensify/App#98975) — open, also involves filtering plus Search request/loading state.
• [$250] Saved search-Total spend is not shown right after saving the search results (Expensify/App#96419) — open, touches the shouldCalculateTotals path referenced above.

---

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

---

view run · no recording available

[melvin-bot]

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

[melvin-bot]

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

[marufsharifi]

@iwiznia, you’re right. Could you please assign this to @elirangoshen and me so we can work on fixing it? Thanks!

[iprasen]

Proposal

What is the root cause of that problem?

1. When a filter changes (such as Merchant in TextFilterPopup), route params update with a new queryJSON.hash.
2. useSearchPageSetup notices that snapshot data for this new hash is not yet in Onyx (isSnapshotDataLoaded === false) and immediately dispatches search({queryJSON, offset: 0, shouldSaveRecentSearch: true, ...}).
3. Meanwhile, SearchPageWide / SearchPageNarrow displays SearchLoadingSkeleton while snapshot data loads.
4. When the search request finishes, it deletes ${hash}_0 from inFlightSearchRequests in Search.ts and merges the snapshot into Onyx.
5. The skeleton unmounts and <SearchWithNavigationDeferredMount key={queryJSON.hash}> mounts a fresh instance of <Search>.
6. On mount, <Search> runs its mount useEffect. Because the page setup request already completed:
   • searchResults?.search?.isLoading is false.
   • inFlightSearchRequests.get(dedupeKey) is undefined.
   • It falls through and triggers a second, redundant handleSearch({queryJSON, offset: 0, ...}) call.

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

Coordinate the page setup and component mount using a one-shot handover token via SearchResultsContext:

1. In SearchResultsProvider, maintain a pageRequestedHashesRef set with two actions:
   • markHashAsPageRequested(hash: number): registers that the page setup has initiated the search for this hash.
   • consumePageRequestedHash(hash: number): boolean: returns true and deletes the entry from the set if present.
2. In useSearchPageSetup, whenever search(...) is dispatched for a missing snapshot, call markHashAsPageRequested(hash).
3. In Search/index.tsx, inside the mount useEffect right before handleSearch, add an early return:

   if (searchRequestOffset === 0 && consumePageRequestedHash(queryJSON.hash)) {
       return;
   }

This cleanly prevents the duplicate request while preserving:

• Pagination (offset > 0).
• Background cache revalidations on tab revisits (where snapshot data is already loaded in Onyx, so markHashAsPageRequested is not called and consumePageRequestedHash returns false).

What alternative solutions did you explore? (Optional)

• Extending deduplication TTL in Search.ts: Risks stale caching across intentional fast user refetches and doesn't address the coordination between setup skeleton and component mount.
• Adding a blanket isDataLoaded guard in Search: Would break expected background cache revalidations when revisiting tabs.

[melvin-bot]

📣 @iprasen! 📣
Hey, it seems we don’t have your contributor details yet! You'll only have to do this once, and this is how we'll hire you on Upwork.
Please follow these steps:

1. Make sure you've read and understood the contributing guidelines.
2. Get the email address used to login to your Expensify account. If you don't already have an Expensify account, create one here. If you have multiple accounts (e.g. one for testing), please use your main account email.
3. Get the link to your Upwork profile. It's necessary because we only pay via Upwork. You can access it by logging in, and then clicking on your name. It'll look like this. If you don't already have an account, sign up for one here.
4. Copy the format below and paste it in a comment on this issue. Replace the placeholder text with your actual details.
   
   Format:

Contributor details
Your Expensify account email: <REPLACE EMAIL HERE>
Upwork Profile Link: <REPLACE LINK HERE>

[iprasen]

Contributor details
Your Expensify account email: iprasen09@gmail.com
Upwork Profile Link: https://www.upwork.com/freelancers/~0190b8cf3bf6b6e942

[melvin-bot]

✅ Contributor details stored successfully. Thank you for contributing to Expensify!