[$250] Reports - Total expenses at the footer does not update when more expenses are loaded

[nlemma]

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.2.2-0
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from TestRail: #69459
Email or phone of affected tester (no customers): N/A
Issue reported by: Applause Internal Team
Device used: macOS Sequoia 15.5 - Chrome
App Component: Search

Action Performed:

Precondition:

• Account has more than 50 expenses that are pending approval.

1. Go to staging.new.expensify.com
2. Go to Reports.
3. Go to Approve under "To-do" section.
4. Remember the amount of total expenses at the footer (in my case, it's 71 expenses).
5. Scroll to the bottom to reveal more expenses.
6. Select all expenses via checkbox.
7. The total expenses in the list is now 96.
8. Unselect all expenses.
9. The amount of total expenses at the footer is still not updated. It still shows 71 expenses, when there are 96 expenses now after scrolling down to the bottom.

Expected Result:

The total expenses at the footer should update after scrolling down to load more expenses - it should show 96 expenses instead of 71 expenses.

Actual Result:

The total expenses at the footer does not update after scrolling down to load more expenses - it still shows 71 expenses when there are 96 expenses.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug6938233_1757318694682.Screen_Recording_2025-09-08_at_15.57.20.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~021965068390053998831
• Upwork Job ID: 1965068390053998831
• Last Price Increase: 2025-09-15

[melvin-bot]

Triggered auto assignment to @joekaufmanexpensify (Bug), see https://stackoverflow.com/c/expensify/questions/14418 for more details. Please add this bug to a GH project, as outlined in the SO.

[JS00001]

We don't want to remove the offset check. Calculating totals is expensive, and calculates the total for the entire view. We shouldn't be calculating it every time we scroll

[ShridharGoel]

Proposal

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

On the Reports > Approve (To‑do) search view, the footer ("Expenses:" / "Total spend:") shows an incorrect total number of expenses after the user scrolls to load additional pages of results. Example: Initially 71 expenses are shown; after scrolling more are loaded (total visible grows to 96) but the footer still displays 71. This creates confusion and undermines trust in bulk selection and export actions.

What is the root cause of that problem?

The server only calculates metadata.count and metadata.total on the first page when shouldCalculateTotals=true. Subsequent paginated fetches set shouldCalculateTotals=false, so the snapshot's search.metadata.count is never updated. The footer relied solely on that static metadata.count (and metadata.total), ignoring how many transaction rows are now present in the locally cached snapshot after pagination.

Relevant existing code (footer aggregation relied on metadata.count):

• Footer logic (uses metadata.count / metadata.total directly)
  

  App/src/pages/Search/SearchPage.tsx

  Lines 673 to 682 in 64b0db5

  	const footerData = useMemo(() => {
  	const shouldUseClientTotal = selectedTransactionsKeys.length > 0 && !areAllMatchingItemsSelected;
  	const currency = metadata?.currency;
  	const count = shouldUseClientTotal ? selectedTransactionsKeys.length : metadata?.count;
  	const total = shouldUseClientTotal ? Object.values(selectedTransactions).reduce((acc, transaction) => acc - (transaction.convertedAmount ?? 0), 0) : metadata?.total;
  	return {count, total, currency};
  	}, [areAllMatchingItemsSelected, metadata?.count, metadata?.currency, metadata?.total, selectedTransactions, selectedTransactionsKeys.length]);

• Logic determining when totals are calculated only on first page (deriving shouldCalculateTotals):

  App/src/components/Search/index.tsx

  Lines 261 to 289 in 64b0db5

  	const shouldCalculateTotals = useMemo(() => {
  	if (offset !== 0) {
  	return false;
  	}
  	const savedSearchValues = Object.values(savedSearches ?? {});
  	if (!savedSearchValues.length && !searchKey) {
  	return false;
  	}
  	const eligibleSearchKeys: Partial<SearchKey[]> = [
  	CONST.SEARCH.SEARCH_KEYS.SUBMIT,
  	CONST.SEARCH.SEARCH_KEYS.APPROVE,
  	CONST.SEARCH.SEARCH_KEYS.PAY,
  	CONST.SEARCH.SEARCH_KEYS.EXPORT,
  	CONST.SEARCH.SEARCH_KEYS.STATEMENTS,
  	CONST.SEARCH.SEARCH_KEYS.UNAPPROVED_CASH,
  	CONST.SEARCH.SEARCH_KEYS.UNAPPROVED_CARD,
  	CONST.SEARCH.SEARCH_KEYS.RECONCILIATION,
  	];
  	if (eligibleSearchKeys.includes(searchKey)) {
  	return true;
  	}
  	for (const savedSearch of savedSearchValues) {
  	const searchData = buildSearchQueryJSON(savedSearch.query);
  	if (searchData && searchData.similarSearchHash === similarSearchHash) {

• Effect triggering paginated searches (invokes handleSearch with shouldCalculateTotals and offset):

  App/src/components/Search/index.tsx

  Lines 359 to 371 in 64b0db5

  	useEffect(() => {
  	const focusedRoute = findFocusedRoute(navigationRef.getRootState());
  	const isMigratedModalDisplayed = focusedRoute?.name === NAVIGATORS.MIGRATED_USER_MODAL_NAVIGATOR || focusedRoute?.name === SCREENS.MIGRATED_USER_WELCOME_MODAL.ROOT;
  	if ((!isFocused && !isMigratedModalDisplayed) || isOffline) {
  	return;
  	}
  	handleSearch({queryJSON, searchKey, offset, shouldCalculateTotals});
  	// We don't need to run the effect on change of isFocused.
  	// eslint-disable-next-line react-compiler/react-compiler
  	// eslint-disable-next-line react-hooks/exhaustive-deps
  	}, [handleSearch, isOffline, offset, queryJSON, searchKey, shouldCalculateTotals]);

Because later pages don't update totals, the UI keeps showing the original first-page count.

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

1. Extract a pure helper computeSearchFooterData({metadata, searchData, selectedTransactions, areAllMatchingItemsSelected}) in src/libs/computeSearchFooterData.ts.

2. Selection path: If there is a partial (not “select all”) selection, return {count: #selected, total: aggregated convertedAmount, currency} immediately - no snapshot scan.

3. Non‑selection path: Start from server metadata.count/total. Perform a single pass over searchData counting only keys with the transaction prefix. While scanning, accumulate a derived total (subtracting convertedAmount to match existing sign convention). If derived count exceeds the original server count, override count (and total only if we actually derived any non‑zero converted amounts).

4. Skip any additional passes, early decisions, or per‑row computations: the helper is wrapped in a useMemo whose dependencies change only when pagination delivers new data, selection changes, or metadata reference changes - ordinary scrolling / row virtualization does not trigger recomputation.

5. Keep server values when: (a) we have no snapshot data yet, (b) all matching items are selected (server remains authoritative for whole result set), or (c) derived count never exceeds server count.

const footerData = useMemo(() => {
-       const shouldUseClientTotal = selectedTransactionsKeys.length > 0 && !areAllMatchingItemsSelected;

-      const currency = metadata?.currency;
-       const count = shouldUseClientTotal ? selectedTransactionsKeys.length : metadata?.count;
-       const total = shouldUseClientTotal ? Object.values(selectedTransactions).reduce((acc, transaction) => acc - (transaction.convertedAmount ?? 0), 0) : metadata?.total;

-       return {count, total, currency};
-   }, [areAllMatchingItemsSelected, metadata?.count, metadata?.currency, metadata?.total, selectedTransactions, selectedTransactionsKeys.length]);

+       return computeSearchFooterData({
+           metadata,
+           searchData: searchResults?.data,
+           selectedTransactions: (selectedTransactions as unknown as Record<string, any>) ?? {},
+           areAllMatchingItemsSelected,
+       });
+   }, [areAllMatchingItemsSelected, metadata, searchResults?.data, selectedTransactions]);

export default function computeSearchFooterData({metadata, searchData, selectedTransactions, areAllMatchingItemsSelected}: ComputeSearchFooterDataParams): SearchFooterData {
    const currency = metadata?.currency;
    const selectedKeys = Object.keys(selectedTransactions ?? {});
    const hasPartialSelection = selectedKeys.length > 0 && !areAllMatchingItemsSelected;

    if (hasPartialSelection) {
        const selectionTotal = Object.values(selectedTransactions).reduce((acc, tx) => {
            const amount = (tx as unknown as {convertedAmount?: number})?.convertedAmount;
            return acc - (amount ?? 0);
        }, 0);
    return {count: selectedKeys.length, total: selectionTotal, currency};
    }

    const serverCount = metadata?.count ?? 0;
    const serverTotal = metadata?.total;

    if (!searchData) {
    return {count: metadata?.count, total: serverTotal, currency};
    }

    const transactionPrefix = ONYXKEYS.COLLECTION.TRANSACTION;
    let derivedCount = 0;
    let derivedTotal = 0;
    let shouldOverride = false;

    for (const key in searchData) {
        if (!key.startsWith(transactionPrefix)) {
            continue;
        }
        derivedCount += 1;
        const value = searchData[key];
        const amount = (value as {convertedAmount?: number})?.convertedAmount;
        if (typeof amount === 'number') {
            derivedTotal -= amount;
        }
        if (!shouldOverride && derivedCount > serverCount) {
            shouldOverride = true;
        }
    }

    if (shouldOverride) {
        return {count: derivedCount, total: derivedTotal !== 0 ? derivedTotal : serverTotal, currency};
    }

    return {count: metadata?.count, total: serverTotal, currency};
}

Screen.Recording.2025-09-08.at.5.56.14.PM.mov

What specific scenarios should we cover in automated tests to prevent reintroducing this issue in the future?

Add / update tests around the footer calculation logic (likely a unit test for a small pure helper we could extract, e.g. computeFooterData(metadata, snapshotData, selectedTransactions, areAllMatchingItemsSelected)).

[melvin-bot]

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

[melvin-bot]

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