Storm of `Search` API calls on the Spend tab with large result sets

[TMisiukiewicz]

Problem

On the Spend tab, sections with a large result set (~5k reports) sometimes end up firing a storm of Search requests back-to-back instead of a single request. It is intermittent and I have not pinned down a trigger yet:

• it happens after paginating a section several times (multiple Search calls for successive offsets),
• but it also happens simply on navigating back to the Spend tab from another tab, with no scrolling involved.

Impact: a burst of redundant backend requests per user, request queue congestion, a stalled/spinning list, and a pile of redundant Onyx writes and re-renders as each response lands — heavy on slower devices.

Root cause is unknown so far. Opening this to track finding it: capture the burst with the offset and params of every call in the sequence, identify what re-issues the requests, and fix it.

Issue Owner

Current Issue Owner: @ZhenjaHorbach

Issue Owner

Current Issue Owner: @daledah

[MelvinBot]

Proposal

Confidence: Medium. The mechanism below is convergent across three independent code traces and explains both reported triggers, but it is not confirmed against a production log or a live repro. The instrumentation in change 4 is what turns this into certainty.

What is the root cause of that problem?

fetchMoreResults has no synchronous "a page request is already outbound" latch, and the gate it does use is blind for a window that can last seconds. Every re-check inside that window bumps offset by another 50 and fires another Search.

1. Pagination is driven by one piece of component state, offset (Search/index.tsx:158). onEndReached → fetchMoreResults bumps it, and the main effect (:404-465) turns each bump into one request. Nothing is set synchronously to mark the bump.
2. The in-flight gate shouldShowLoadingMoreItems (:378) is derived from the Onyx snapshot — but search() defers its own optimistic isLoading: true write behind waitForWrites(). Until the write queue drains, the snapshot still says "not loading". That gate also requires search.offset > 0, so any in-flight offset: 0 refresh (e.g. refreshSearchAfterReportAction after a bulk Pay/Approve) leaves pagination completely ungated.
3. What re-arms the check without the user scrolling: FlashList v2 clears its end-reached latch on every data identity change, then re-checks bounds after every commit and every scroll event. <Search>'s data is a freshly-allocated array from the chartData memo, whose dep surface churns constantly at ~5k rows — and each search() itself writes the snapshot 2-3 times, so the storm feeds itself.
4. Nothing downstream absorbs it: the dedupe key is `${hash}_${offset}` (Search.ts:1160), so successive-offset calls are never deduped by design, and the entry is deleted the instant the request settles (:1268-1271) so serial re-fires aren't either.

Why large result sets: burst length is bounded by floor((allDataLength - offset) / 50). Pages accumulate in the snapshot, so a session that has already paginated deep into a 5k section has a large bound — the same glitch that costs 1-2 requests on a small list costs dozens here. This matches "it happens after paginating a section several times".

Why it also happens on tab return with no scrolling: the Spend tab is frozen, not unmounted (freezeOnBlur), so offset and scroll position both survive. On re-focus the list is scrolled back to its previous near-bottom position, nothing is in flight so the gate is open, and the unfreeze commit flushes accumulated Onyx updates as several new data references in quick succession — several onEndReached, same cascade, no user gesture.

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

1. Add a synchronous re-entrancy latch to fetchMoreResults (Search/index.tsx:806-812) — a ref holding the highest requested offset, set in the same tick as setOffset, cleared when that offset's request settles. Re-entrancy must not depend on an Onyx round-trip. This alone closes the main path.
2. Stop shouldShowLoadingMoreItems from depending on search.offset > 0 (:378) so an in-flight offset: 0 refresh also blocks pagination. Use the requested-offset ref from change 1 instead.
3. Harden inFlightSearchRequests (Search.ts:1160-1271): keep a short post-completion cooldown instead of deleting in .finally, and drop the type === EXPENSE gate on needsTotalsUpgrade (:1163) — Spend's Submit/Approve/Pay/Export sub-tabs are EXPENSE_REPORT, so that upgrade is dead for exactly the searches that request totals, leaving count undefined and re-arming the totals retry at :467-498. The cooldown was the accepted recommendation on [Due for payment 2026-08-25] Search API re-fires with an identical query hash every 2-8 seconds — 26% of all Search traffic is duplicate #98048 and is not in the code today.
4. Instrument search() — this is the "capture the burst" ask in the issue. There is currently no log at dispatch and no caller identity anywhere in Search.ts. Add a source string parameter and log hash / offset / shouldCalculateTotals / source on every dispatch and every suppressed call. The offsets alone then discriminate the mechanisms: same hash at ascending offsets = this cascade; same hash at a constant offset = the retry or highlight chains; distinct hashes all at offset 0 = the Home tab's "Your spend" section, not this page at all.

What alternative solutions did you explore? (Optional)

• Debouncing onEndReached — rejected. It narrows the window but doesn't close it, and the window scales with the write-queue depth, which is unbounded.
• Stabilising the data array identity so FlashList stops re-arming — a real improvement for a 5k list, but it treats the amplifier rather than the missing latch, and any future dep change reopens it.
• Query identity churn (SearchQueryUtils.ts:756-760 — the cache is FIFO, not LRU, so the hot Spend query can be evicted by 50 unrelated calls and re-fire both effects with zero semantic change). Real, worth fixing, but it re-fires at the same offset, so it can't produce the successive-offset pattern described.
• The Home tab's useYourSpendData (:605-654) fires 1 + N_cards + 2 searches from an effect with isFocused in its deps — a cleaner literal match for "burst on returning to a tab". Ruled out as this issue because the report is explicit about pagination on the Search page, but note the naming trap: common.spend labels the Search tab while "Your spend" is a Home section. The source tag in change 4 settles it definitively.

Live web test (empty test account — corroborating, not conclusive)

Result: pass — On dev NewDot web, the initial Spend-tab load fired 3 Search POSTs within ~467 ms even though the account has zero expenses. Pagination could not be exercised. Request bodies aren't exposed by the tooling, so offsets and shouldCalculateTotals were not observable.

Step	Status	Observation
Count Search calls on initial Spend tab load	pass	3 POST /api/Search? at 14:45:39.041 / .407 / .508 plus 1 OpenSearchPage; offset and shouldCalculateTotals not visible (headers only, no request body)
Count Search calls per pagination scroll	pass	Account shows "No expenses yet"; scroll reported already at bottom; 0 new Search calls fired
Count Search calls on Home → Spend re-navigation	pass	Only 1 Search + 1 OpenSearchPage; fewer than the initial 3-call load

Three near-identical calls on a single mount of an empty list shows redundant firing exists at baseline, independent of result-set size.

Evidence (1)

Spend > Expenses empty state on the test account; three Search calls still fired on this mount

Other amplifiers found (secondary — fix the latch first)

• Grouped-view totals retry (Search/index.tsx:467-498): when validGroupBy is set the count !== undefined disarm is skipped, so it fires an extra full Search the instant isLoading goes false — roughly doubling requests per page on grouped sections. The ref is re-armed by the main effect on any dep change during a request, so it is not one-shot.
• pendingUpgradeRequest adds a request rather than removing one (Search.ts:1268-1271): <Search>'s fire omits shouldSaveRecentSearch while useSearchPageSetup.ts:95 passes true, so a collision at offset 0 deterministically doubles the request.
• Callers hard-coding isLoading: false bypass the only top-of-function guard entirely (Search.ts:1156) — including useSearchPageSetup.ts:95 and Search/index.tsx:486.
• useSearchHighlightAndScroll (:165-198) latches a deferred refetch while the tab is blurred and releases it on re-focus; its re-entry gate is cleared by every snapshot change, and usePrevious(transactions) drains one render at a time, so a frozen-period transaction diff is replayed as a chain of sequential searches — never overlapping, therefore never deduped.

Related issues

• [Due for payment 2026-08-25] Search API re-fires with an identical query hash every 2-8 seconds — 26% of all Search traffic is duplicate #98048 — identical-hash Search re-firing every 2-8s. Fixed by PR fix: stop Search re-firing an identical query on unrelated Onyx updates #98305 / fix: reland Search re-fire fix with the deploy blocker regressions closed #98558, but the accepted proposal's post-completion cooldown is not present in the code today; only the in-flight map landed.
• [Due for payment 2026-09-02] Reports – "Select all" never shows the green count button; loading state stuck by a second Search call #99298 — a second Search call wiping totals on Reports. PR fix: prevent Select All button from spinning forever on Reports page #99316 added the pendingUpgradeRequest upgrade path, still EXPENSE-gated.
• Spend tab previous-month reports and expenses lag for admin users in New Expensify #97485 — Spend tab lag for admin users with large data sets; plausibly the same request pressure.

---

Next Steps for Contributor+ team:
To accept: @MelvinBot implement [this](https://github.com/Expensify/App/issues/99914) to create a draft PR.
To refine: @MelvinBot <your feedback> — e.g. to land change 4 (instrumentation) alone first and pin the trigger from production logs before touching the pagination gate.
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 - @daledah (External)

[melvin-bot]

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