[$250] Saved search-Total spend is not shown right after saving the search results

[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.36-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/13176922/test-cases/41237510
Email or phone of affected tester (no customers): N/A
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: MacBook Air 26.5.2 Chrome, iPhone 15 iOs 26.5.2
App Component: Search

Action Performed:

1. Create a workspace
2. Create a manual expense, in the merchant field enter Walmart
3. Navigate to the Spend tab, click the Search icon
4. Enter type:expense merchant:walmart, apply the search
5. Click the Bookmark icon and save the search
6. Observe the right bottom corner or the saved search page - expenses count and total spend do not appear
7. Open a different page, like Expenses, then go back to the Saved search - now the total spend and the expense count are shown

Expected Result:

Expenses count and total spend are shown after saving the search

Actual Result:

Expenses count and Total spend are not shown on the page right after saving the search results

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7210841_1784308653636.Total_spend.mp4

View all open jobs on GitHub

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

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022078179201944364821
• Upwork Job ID: 2078179201944364821
• Last Price Increase: 2026-09-25

Issue Owner

Current Issue Owner: @parasharrajat

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

[MelvinBot]

Proposal

Please re-state the problem that we are trying to solve in this issue.

After saving an ad-hoc search via the Bookmark icon, the expense count and total spend footer does not appear. It only shows up after navigating away and back to the saved search.

What is the root cause of that problem?

The totals footer only renders when totals are allowed and the snapshot already contains a server-computed count:

src/components/Search/SearchSelectionFooter.tsx:30

const shouldShowFooter = (!areAllMatchingItemsSelected && selectedTransactionsKeys.length > 0) || (shouldAllowFooterTotals && !!metadata?.count);

For an ad-hoc query like type:expense merchant:walmart, totals are not requested on the initial search, and that initial search actively nulls out count/total in the snapshot (src/libs/actions/Search.ts:675,693) via shouldCalculateTotals === false.

Saving the search writes SAVED_SEARCHES[hash] without changing the hash (src/libs/actions/Search.ts:757-796). That flips useSearchShouldCalculateTotals to true (the query is now a saved search), so shouldAllowFooterTotals becomes true — but metadata.count is still null, so the footer stays hidden.

The page-level effect that would re-fetch with totals re-runs (because shouldCalculateTotals is in its deps), but bails out early because the snapshot for that hash is already loaded:

src/hooks/useSearchPageSetup.ts:72-76

if (isSnapshotDataLoaded || isSnapshotSearchLoading) {
    return;
}
search({queryJSON, searchKey: currentSearchKey, offset: 0, shouldCalculateTotals, ...});

So no new search-with-totals is issued after save, and count stays null. Navigating away and back re-enters this path (snapshot no longer treated as freshly loaded / remount), finally firing search() with shouldCalculateTotals: true, which populates count/total and reveals the footer.

Full data flow & evidence

1. Ad-hoc query runs → useSearchShouldCalculateTotals returns false (not an eligible suggested search, not yet saved) → useSearchPageSetup fires search({shouldCalculateTotals: false}) → getOnyxLoadingData sets snapshot.search.count = null (Search.ts:693).
2. Bookmark → saveSearch merges SAVED_SEARCHES[hash] optimistically; hash unchanged.
3. useSearchShouldCalculateTotals flips to true; shouldAllowFooterTotals true, but metadata.count still null → footer returns null.
4. useSearchPageSetup effect re-runs but returns early at isSnapshotDataLoaded → no re-fetch. ← bug manifests here
5. Navigate away + back → effect fires search({shouldCalculateTotals: true}) → server returns totals → footer appears.

The in-component retry-with-totals effect at src/components/Search/index.tsx:392-437 can't rescue this: it only arms its retry flag while a search is in-flight (isLoading) with count === undefined; here the search already completed and count is null, not undefined.

Confidence: high — deterministic frontend code path, no hash change involved.

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

Allow useSearchPageSetup to re-issue search() with totals when shouldCalculateTotals has just transitioned false → true for an already-loaded snapshot whose search.count is null/undefined, instead of always returning early on isSnapshotDataLoaded.

Concretely, in useSearchPageSetup.ts:72, refine the guard so a loaded snapshot that still needs totals (shouldCalculateTotals && snapshot.search.count == null) does not short-circuit the search() call. This must be validated against the snapshot-loading guard comment above it so it doesn't wipe hasMoreResults (i.e. re-fetch with offset: 0 only, and only when totals are actually missing).

An alternative narrower fix is to have saveSearch (or the saved-search transition) explicitly trigger a totals re-fetch for the current hash.

What alternative solutions did you explore?

Fixing it in the footer/index.tsx retry effect was considered but rejected — the retry flag only arms during an in-flight search, so it can't cover a completed ad-hoc search that later becomes saved.

Related issues

• [Due for payment 2026-08-21][$250] Search: show expense count and total when "Select all matching items" is active #94907 — Search: show expense count and total when "Select all matching items" is active — touches the same footer/totals logic (possibly related, not a duplicate).

---

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

[nabi-ebrahimi]

Proposal

What is the root cause of that problem?

A normal ad-hoc expense search is loaded without server totals because useSearchShouldCalculateTotals() only enables totals for eligible suggested searches or hashes that already exist in ONYXKEYS.SAVED_SEARCHES (https://github.com/Expensify/App/blob/main/src/hooks/useSearchShouldCalculateTotals.ts#L11-L49), and search() sends that boolean to the backend as shouldCalculateTotals (https://github.com/Expensify/App/blob/main/src/libs/actions/Search.ts#L913-L972). After the user saves the current search, SearchSavePage calls saveSearch() and immediately navigates back (https://github.com/Expensify/App/blob/main/src/pages/Search/SearchSavePage.tsx#L161-L169), while saveSearch() only adds the current hash to ONYXKEYS.SAVED_SEARCHES optimistically (https://github.com/Expensify/App/blob/main/src/libs/actions/Search.ts#L757-L796).

That saved-search Onyx update makes the current search eligible for totals, but it can happen while the underlying Search screen is not focused behind the save RHP. The Search component’s refetch effect returns early when the screen is not focused (https://github.com/Expensify/App/blob/main/src/components/Search/index.tsx#L376-L380), and that effect intentionally does not rerun on focus changes (https://github.com/Expensify/App/blob/main/src/components/Search/index.tsx#L403-L414). So the active snapshot keeps the old no-totals response, and the footer stays hidden because it only renders saved-search totals when metadata.count exists (https://github.com/Expensify/App/blob/main/src/components/Search/SearchSelectionFooter.tsx#L22-L33). Navigating away and back later causes the search flow to run again, this time with totals enabled.

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

Update src/components/Search/index.tsx so the Search screen explicitly re-fetches the current snapshot when totals become required for the current query but the loaded snapshot still has no search.count.

The smallest fix is to add a focused-return/refocus path near the existing totals retry logic. It should check that:

• the screen is focused,
• the app is online,
• shouldCalculateTotals is true,
• searchResults?.search?.count is still undefined,
• the search is not already loading,
• there are no blocking search errors,
• and we are on the first page (offset === 0).

When those conditions are met, call the existing handleSearch() with the current queryJSON, currentSearchKey, offset, prevReportsLength: filteredDataLength, and shouldCalculateTotals: true. This keeps the fix in the component that already owns snapshot refreshes and reuses the same backend totals path instead of inventing separate saved-search behavior.

To keep this narrowly scoped, we can either add a useFocusEffect for this specific missing-totals case, or include focus in a small helper dedicated to the totals retry condition rather than making the main search effect refetch on every focus return.

What alternative solutions did you explore? (Optional)

I also considered triggering a totals search directly from SearchSavePage after saveSearch(), but that would make the save form responsible for refreshing search snapshot metadata. Keeping the fix in Search is cleaner because the Search screen already owns shouldCalculateTotals, loading state, offset, current search key, and snapshot refresh behavior.

[MobileMage]

Proposal

Please re-state the problem that we are trying to solve in this issue.

After running an ad-hoc search (e.g. type:expense merchant:walmart) and saving it via the Bookmark icon, the footer with the expenses count and Total spend does not appear on the saved search page. It only shows up after navigating to another page and coming back to the saved search.

What is the root cause of that problem?

The footer totals (count/total) are not computed on the client — they come from the Search API response, and the API only returns them when the request is sent with shouldCalculateTotals: true. useSearchShouldCalculateTotals returns true only for suggested searches or when the current hash exists in ONYXKEYS.SAVED_SEARCHES (isSavedSearch = searchHash !== undefined && savedSearches && !!savedSearches[searchHash]). So the initial ad-hoc search runs with shouldCalculateTotals: false, and getOnyxLoadingData in src/libs/actions/Search.ts even explicitly clears totals in that case (shouldClearTotals writes {count: null, total: null, currency: null} to the snapshot). Consequently the snapshot for this hash has no search.count, and SearchSelectionFooter hides the footer because shouldShowFooter requires shouldAllowFooterTotals && !!metadata?.count.

When the user taps the Bookmark icon, SearchSaveButton navigates to the SEARCH_SAVE RHP, and SearchSavePage calls saveSearch(), which optimistically merges the hash into ONYXKEYS.SAVED_SEARCHES. That write flips shouldCalculateTotals to true inside <Search> (src/components/Search/index.tsx), which re-runs the search-trigger effect (it has shouldCalculateTotals in its deps) — and this is exactly where the re-fetch is supposed to happen. But at that moment the save RHP is still on top of the Search screen, so useIsFocused() for <Search> is false, and the effect bails out on its focus guard:

App/src/components/Search/index.tsx

Lines 378 to 381 in 30eef09

	const comingBackOnlineWithNoResults = prevIsOffline && !isOffline && isEmptyObject(searchResults?.data);
	if (!comingBackOnlineWithNoResults && ((!isFocused && !isMigratedModalDisplayed) || isOffline)) {
	return;
	}

The guard already carves out one "modal on top of Search" case (isMigratedModalDisplayed) but not the save RHP. And because isFocused is deliberately excluded from the effect's dependency array ("We don't need to run the effect on change of isFocused", L412-L414), the effect never re-runs when the RHP closes and Search regains focus. The shouldCalculateTotals: true request is therefore never issued: the snapshot keeps count: null, and shouldShowFooter stays false in SearchSelectionFooter:

App/src/components/Search/SearchSelectionFooter.tsx

Lines 28 to 30 in 30eef09

	const metadata = searchResults?.search;
	const selectedTransactionsKeys = Object.keys(selectedTransactions ?? {});
	const shouldShowFooter = (!areAllMatchingItemsSelected && selectedTransactionsKeys.length > 0) || (shouldAllowFooterTotals && !!metadata?.count);

Navigating to another page and back "fixes" it because useSearchPageSetup (and the remounted <Search> effect) triggers a fresh search() while the page is focused, this time with shouldCalculateTotals: true since the hash is now in savedSearches, so the API returns count/total and the footer renders.

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

The fix belongs in the focus guard of the search-trigger effect in src/components/Search/index.tsx. The guard's intent is "don't fire searches for a Search page the user isn't looking at" — but when only an RHP (like the save-search page) is covering it, the Search page is still visible underneath and re-fetching is both safe and desired. The file already imports isSearchTopmostFullScreenRoute (it uses it in the blur-cleanup effect at L477), which returns true exactly in this situation: Search is still the topmost fullscreen route even though an RHP holds navigation focus. We should extend the guard the same way the migrated-user-modal exception already does:

const isSearchVisibleUnderOverlay = isSearchTopmostFullScreenRoute();
if (!comingBackOnlineWithNoResults && ((!isFocused && !isMigratedModalDisplayed && !isSearchVisibleUnderOverlay) || isOffline)) {
    return;
}

With this change, the optimistic SAVED_SEARCHES write from saveSearch() flips shouldCalculateTotals to true, the effect re-runs, passes the guard (Search is still the topmost fullscreen route behind the RHP), and calls handleSearch with shouldCalculateTotals: true, so the snapshot receives count/total/currency and the footer appears immediately after saving. This is safe for other scenarios: when the user actually leaves Search (opens a report, goes to Settings, etc.), Search is no longer the topmost fullscreen route, so the guard still blocks background searches exactly as before; the effect's other deps (queryJSON, offset, currentSearchKey) only change from user actions performed on the Search page itself, so no new spurious requests are introduced while unrelated RHPs are open. The existing loading/retry machinery (shouldRetrySearchWithTotalsOrGroupedRef) already handles the case where a request is in flight when the flag flips.

What alternative solutions did you explore? (Optional)

We considered keeping the focus guard intact and instead recording the skipped run in a ref (mirroring the existing shouldRetrySearchWithTotalsOrGroupedRef pattern), then re-issuing the search from a useFocusEffect when the page regains focus after the RHP closes. It works, but it adds a second retry mechanism and delays the fetch until after the modal dismiss animation, whereas extending the existing visibility exception fires the request immediately and matches the pattern the guard already uses for the migrated-user modal. We also considered calling search() directly from saveSearch(), but the action layer has no access to the page's searchKey/offset context and that would duplicate the trigger logic that already lives in <Search>.

[ahmdshrif]

🚨 Edited by proposal-police: This proposal was edited at 2026-07-17 18:06:14 UTC.

Proposal

Please re-state the problem that we are trying to solve in this issue.

After saving the current search via the bookmark icon, the footer with "Expenses: N" and "Total spend: X" does not appear on the saved-search results page. It only appears after navigating to another page and coming back.

What is the root cause of that problem?

The footer is rendered only when the search snapshot contains server-computed totals: shouldShowFooter requires !!metadata?.count, where metadata is searchResults.search —

App/src/components/Search/SearchSelectionFooter.tsx

Lines 28 to 32 in 30eef09

	const metadata = searchResults?.search;
	const selectedTransactionsKeys = Object.keys(selectedTransactions ?? {});
	const shouldShowFooter = (!areAllMatchingItemsSelected && selectedTransactionsKeys.length > 0) || (shouldAllowFooterTotals && !!metadata?.count);
	if (!shouldShowFooter) {

. Those totals are returned by the Search API only when we request them with shouldCalculateTotals: true.

Whether we request totals is derived reactively: a query is totals-eligible only once it exists in savedSearches —

App/src/hooks/useSearchShouldCalculateTotals.ts

Lines 46 to 48 in 30eef09

	const isSavedSearch = searchHash !== undefined && savedSearches && !!savedSearches[searchHash];
	return isSuggestedSearchWithTotals || isSavedSearch;

. So the original Search request (step 4, before saving) legitimately ran with shouldCalculateTotals: false, and the snapshot has no count/total.

When the user saves, saveSearch optimistically merges the hash into savedSearches —

App/src/libs/actions/Search.ts

Lines 761 to 773 in 30eef09

	const optimisticData: Array<OnyxUpdate<typeof ONYXKEYS.SAVED_SEARCHES>> = [
	{
	onyxMethod: Onyx.METHOD.MERGE,
	key: `${ONYXKEYS.SAVED_SEARCHES}`,
	value: {
	[queryJSON.hash]: {
	pendingAction: CONST.RED_BRICK_ROAD_PENDING_ACTION.ADD,
	name: saveSearchName,
	query: queryJSON.inputQuery,
	},
	},
	},
	];

— flipping shouldCalculateTotals to true. The structural problem: both effects that turn that flag into an API call are gated by conditions that are false at the exact moment the flag flips, and nothing re-checks later:

1. The page-level fetch skips because snapshot data is already loaded — it never looks at whether totals are missing:

   App/src/hooks/useSearchPageSetup.ts

   Lines 72 to 74 in 30eef09

   	if (isSnapshotDataLoaded || isSnapshotSearchLoading) {
   	return;
   	}

   .
2. The component-level fetch effect does re-run on the shouldCalculateTotals dep, but saving happens from the SearchSavePage RHP (

   App/src/pages/Search/SearchSavePage.tsx

   Lines 161 to 170 in 30eef09

   	const onSaveSearch = () => {
   	if (!currentSearchQueryJSON) {
   	Navigation.goBack();
   	return;
   	}
   	const newName = name.trim() || currentSearchQueryJSON?.inputQuery;
   	saveSearch({queryJSON: currentSearchQueryJSON, newName});
   	Navigation.goBack();
   	};

   ), so the underlying Search screen is blurred and the effect early-returns on !isFocused:

   App/src/components/Search/index.tsx

   Lines 374 to 381 in 30eef09

   	useEffect(() => {
   	const focusedRoute = findFocusedRoute(navigationRef.getRootState());
   	const isMigratedModalDisplayed = focusedRoute?.name === NAVIGATORS.MIGRATED_USER_MODAL_NAVIGATOR || focusedRoute?.name === SCREENS.MIGRATED_USER_WELCOME_MODAL.DYNAMIC_ROOT;
   	const comingBackOnlineWithNoResults = prevIsOffline && !isOffline && isEmptyObject(searchResults?.data);
   	if (!comingBackOnlineWithNoResults && ((!isFocused && !isMigratedModalDisplayed) || isOffline)) {
   	return;
   	}

   . isFocused is deliberately excluded from the deps (see the comment at

   App/src/components/Search/index.tsx

   Lines 412 to 413 in 30eef09

   	// We don't need to run the effect on change of isFocused.
   	// eslint-disable-next-line react-hooks/exhaustive-deps

   ), so when the RHP closes and focus returns, the effect never re-runs. The flag flip is silently dropped.

This chain explains every detail: right after saving, metadata.count is still undefined, so the whole footer (both the count and the total, which share the one gate) stays hidden; navigating to Expenses and back changes queryJSON/hash, re-running the fetch effect while focused, which finally requests totals and the footer appears. It reproduces on every platform and both layouts because SearchSavePage, useSearchPageSetup, and components/Search/index.tsx are shared (narrow and wide pages both render this component: SearchPageNarrow/index.tsx#L318/#L361 and SearchPageWide.tsx).

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

Use the existing one-shot retry mechanism (shouldRetrySearchWithTotalsOrGroupedRef, already used for the "flag flipped while a search was in flight" case at

App/src/components/Search/index.tsx

Lines 392 to 396 in 30eef09

	if (searchResults?.search?.isLoading) {
	if (validGroupBy || (shouldCalculateTotals && searchResults?.search?.count === undefined)) {
	shouldRetrySearchWithTotalsOrGroupedRef.current = true;
	}
	return;

) to also cover "flag flipped while blurred", and make the retry effect fire on focus return:

// in the early-return branch at index.tsx#L379
if (!comingBackOnlineWithNoResults && ((!isFocused && !isMigratedModalDisplayed) || isOffline)) {
    if (!isOffline && shouldCalculateTotals && searchResults?.search?.count === undefined) {
        shouldRetrySearchWithTotalsOrGroupedRef.current = true;
    }
    return;
}

and in the retry effect at

App/src/components/Search/index.tsx

Lines 416 to 437 in 30eef09

	useEffect(() => {
	if (!shouldRetrySearchWithTotalsOrGroupedRef.current || searchResults?.search?.isLoading || (!shouldCalculateTotals && !validGroupBy)) {
	return;
	}
	// If count is already present, the latest response already contains totals and we can skip the re-query.
	// If we show grouped values we want to retry search either way, the data may be outdated e.g. after deleting an expense.
	if (!validGroupBy && searchResults?.search?.count !== undefined) {
	shouldRetrySearchWithTotalsOrGroupedRef.current = false;
	return;
	}
	shouldRetrySearchWithTotalsOrGroupedRef.current = false;
	handleSearch({
	queryJSON,
	searchKey: currentSearchKey,
	offset,
	shouldCalculateTotals: true,
	prevReportsLength: filteredDataLength,
	isLoading: false,
	});
	}, [filteredDataLength, handleSearch, offset, queryJSON, currentSearchKey, searchResults?.search?.count, searchResults?.search?.isLoading, shouldCalculateTotals, validGroupBy]);

, add !isFocused || to the guard and isFocused to the dependency array. When the save RHP closes, focus returns, the armed ref fires one handleSearch({..., shouldCalculateTotals: true}), the response merges count/total into the snapshot, and the footer renders. The ref is cleared before firing (and cleared early if count already arrived, index.tsx#L423-L426), so there is no re-fetch loop.

Regression safety in one sentence: we only arm an existing one-shot ref in a branch that previously did nothing, and the retry effect still requires the armed ref plus a missing count, so ad-hoc searches, suggested searches, grouped searches, and every ordinary focus regain behave exactly as before.

Why the obvious one-line fix does not work: adding isFocused to the main fetch effect's deps looks sufficient, but it was deliberately excluded (comment at index.tsx#L412-L413) because that makes the effect re-fire a full Search API call every time the screen regains focus — i.e. after closing any RHP (filters, expense preview), not just after saving. Fixing it in saveSearch itself also fails: the action layer has no access to offset/searchKey/in-flight dedupe state that the component machinery manages.

What alternative solutions did you explore? (Optional)

1. Relax the page-level skip guard in useSearchPageSetup.ts#L72 to also fire when shouldCalculateTotals && count === undefined. This fetches totals even sooner (while the RHP is still open), but it has no one-shot protection — if the request errors or returns without count, the effect re-fires each time isSnapshotSearchLoading flips, risking a request loop; it would need an extra error/attempt guard.
2. Compute the footer totals client-side from the loaded rows when metadata.count is missing. Rejected: totals are server-computed on purpose — the result set can exceed the loaded page (limit), so client math shows wrong numbers for larger saved searches.

[melvin-bot]

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

[melvin-bot]

Job added to Upwork: https://www.upwork.com/jobs/~022078179201944364821

[samranahm]

Proposal

What is the root cause of that problem?

When a user saves a search, Navigation.setParams is called (via SearchAdvancedFiltersProvider's applyFilters or SearchTypeMenuWide's handleTypeMenuItemPress) to update the URL with the new search query. This triggers useSearchPageSetup (called in SearchPage) to fetch new search results.

During the initial render cycle, while the new search results (including count and total metadata) are being fetched and written to the currentSearchResults Onyx key, the SearchSelectionFooter component receives searchResults where searchResults?.search?.count is undefined or 0.

The SearchSelectionFooter component determines its visibility using the shouldShowFooter condition:

App/src/components/Search/SearchSelectionFooter.tsx

Line 29 in 30eef09

const selectedTransactionsKeys = Object.keys(selectedTransactions ?? {});

When no items are selected (which is the case immediately after saving a search), shouldShowFooter effectively becomes (shouldAllowFooterTotals && !!metadata?.count). Since metadata?.count is undefined or 0 during the loading phase, this condition evaluates to false, causing the footer (with expense count and total spend) to be hidden. Navigating away and back allows the Onyx data to fully populate, making the count and total available, and thus showing the footer correctly.

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

The SearchSelectionFooter needs to be aware of the search results' loading state to ensure it is displayed even when the count and total are not yet available. The SearchPageWide component already calculates this loading state via useSearchLoadingState.

1. Modify SearchPageWide to pass the shouldShowLoadingSkeleton prop to SearchSelectionFooter.
   

   App/src/pages/Search/SearchPageWide.tsx

   Line 54 in 30eef09

   searchResults,

   <SearchSelectionFooter
       searchResults={searchResults}
       shouldShowLoadingSkeleton={shouldShowLoadingSkeleton}
   />

2. Update the SearchSelectionFooter component to accept the new shouldShowLoadingSkeleton prop.
   

   App/src/components/Search/SearchSelectionFooter.tsx

   Line 22 in 30eef09

   function SearchSelectionFooter({searchResults}: SearchSelectionFooterProps) {

   function SearchSelectionFooter({searchResults, shouldShowLoadingSkeleton}: SearchSelectionFooterProps) {

3. Modify the shouldShowFooter condition in SearchSelectionFooter to also return true if shouldShowLoadingSkeleton is true. This will ensure the footer is visible during the loading phase, even if metadata?.count is not yet available.
   

   App/src/components/Search/SearchSelectionFooter.tsx

   Line 29 in 30eef09

   const selectedTransactionsKeys = Object.keys(selectedTransactions ?? {});

   const shouldShowFooter =
       shouldShowLoadingSkeleton || (!areAllMatchingItemsSelected && selectedTransactionsKeys.length > 0) || (shouldAllowFooterTotals && !!metadata?.count);

These changes will ensure that the SearchSelectionFooter is displayed immediately after saving a search, providing a better user experience by indicating that the totals are being loaded, rather than being completely absent.

What alternative solutions did you explore? (Optional)

Reminder: Please use plain English, be brief and avoid jargon. Feel free to use images, charts or pseudo-code if necessary. Do not post large multi-line diffs or write walls of text. Do not create PRs unless you have been hired for this job.