Spend - Total spend footer does not always appear when all expenses are selected

[applause-bot]

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: 9.4.34-2
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: #95238
Email or phone of affected tester (no customers): applausetester+khcategory19@applause.expensifail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Mac 26.5 / Chrome
App Component: Money Requests

Action Performed:

Precondition:

• Account has many expenses (100+).

1. Go to staging.new.expensify.com
2. Go to Spend > Expenses.
3. Click Select all checkbox > Select all on this page.
4. Deselect Select all checkbox.
5. Click Select all checkbox > Select all.
6. Deselect Select all checkbox.
7. Repeat Step 5 and 6 until total spend footer does not appear.

Expected Result:

Total spend footer will always appear when all expenses are selected.

Actual Result:

Total spend footer does not always appear when all expenses are selected.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7207975_1784030335366.5.mp4

View all open jobs on GitHub

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

Issue Owner

Current Issue Owner: @lorretheboy

[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/a1e3b54914d10022f0411a8a3d07bf9ede3e1ed791110f9c997d6f6ee4ff6e40

[melvin-bot]

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

[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

Problem

The Total spend footer intermittently disappears when "Select all matching items" is active on an ad-hoc Expenses search (e.g. Spend > Expenses). Repro: rapidly toggle select-all off/on and the server count/total footer eventually stops appearing. This is a regression from #95238 (fix for #94907).

Root Cause

The footer only renders when the server-computed searchResults.search.count is truthy and total is a number. Those values get erased on toggle:

1. Search: show expense count and total when "Select all matching items" is active #95238 made shouldCalculateTotals toggle with areAllMatchingItemsSelected (useSearchShouldCalculateTotals.ts:16-20). For an ad-hoc Expenses search it is true only while all-matching is selected. Deselecting flips it back to false.
2. That flip re-runs the search effect and fires a fresh offset === 0 search without totals. getOnyxLoadingData then optimistically merges {count: null, total: null, currency: null} into the snapshot (Search.ts:675-684) — Onyx MERGE treats null as delete, so the previously fetched totals are wiped immediately, before any response returns.
3. The recovery path that re-requests totals is gated on shouldCalculateTotals still being true when loading finishes (index.tsx:415-436). If the user has already deselected (flag now false), that guard bails and totals are never refetched — so count/total stay cleared and the footer returns null.

Rapid toggling widens the window: a stale in-flight non-totals response can also land after a totals response and re-clear count.

Recommended Fix

Stop clobbering already-fetched totals on a totals-flag flip. In getOnyxLoadingData, only clear count/total/currency when the query hash actually changes (a genuinely new query), not merely because shouldCalculateTotals toggled false on the same query. The stale totals are then simply not refreshed rather than erased, and the footer keeps rendering.

Alternatives considered

• Keep the flag sticky: once all-matching was selected for a hash, don't drop shouldCalculateTotals back to false mid-interaction. Fixes the footer but increases request volume and changes selection semantics.
• Gate the footer on isLoading: retain the last known count/total in SearchSelectionFooter while metadata.isLoading is true. Masks the flicker but leaves the underlying erase in place.

The recommended fix is the most targeted — it addresses the clobber itself. Note this touches src/libs/actions/Search.ts, which is in the App repo, so it's implementable here.

Confidence: High — deterministic client-side ordering issue, proven from code (no logs needed).

Related feature issue: #94907 (the feature this regressed from).

---

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

[lorretheboy]

Checking... I will open fix PR shortly