Home - Infinite loading on Reports>Expenses pg when creating expense from home QAB/FAB for first time

[jponikarchuk]

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: v9.3.40-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: Exploratory around #85427
Email or phone of affected tester (no customers): kiatest.78+ck318266@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Web
App Component: Money Requests

Action Performed:

1. Navigate to staging.new.expensify.com
2. Create new gmail account & create new USD workspace
3. Go to Home page
4. Select either Expense or Distance Quick creation option or select create expense/track distance from FAB
5. Create either manual expense or manual distance expense
6. User redirected to Reports >> Expense page
7. Observe infinite loading displayed

Expected Result:

Expense created from Quick creation bar & FAB for first time should be immediately displayed in Reports >> Expenses page without displaying infinite loading

Actual Result:

Infinite loading displayed on Reports>>Expenses page when creating expense from home Quick creation bar & FAB for first time

Note: Issue happens when creating Per diem, Scan & Map distance expenses for first time from FAB

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Video.mp4

View all open jobs on GitHub

[harryautomazione]

Hi everyone! 👋

I’ve investigated the infinite loading issue that occurs on the Reports > Expenses page when creating an expense for the first time.

🔍 Bug Analysis

The page relies on isSearchDataLoaded in SearchUIUtils.ts to decide whether to render the list or keep showing the loading skeleton/spinner. Currently, this function uses a rigid comparison between the status of the query and the status returned by the server:

https://github.com/Expensify/App/blob/main/App/src/libs/SearchUIUtils.ts#L3937-L3947

function isSearchDataLoaded(searchResults: SearchResults | undefined, queryJSON: SearchQueryJSON | undefined) {
    const {status} = queryJSON ?? {};

    const sortedSearchResultStatus = !Array.isArray(searchResults?.search?.status)
        ? searchResults?.search?.status?.split(',').sort().join(',')
        : searchResults?.search?.status?.sort().join(',');
    const sortedQueryJSONStatus = Array.isArray(status) ? status.sort().join(',') : status;
    
    const isDataLoaded = searchResults?.data !== undefined && searchResults?.search?.type === queryJSON?.type && sortedSearchResultStatus === sortedQueryJSONStatus;

    return isDataLoaded;
}

When building a default/simple query with buildCannedSearchQuery (e.g., just type:expense), the queryJSON.status will be undefined (or empty).
However, the back-end usually returns the results with a search.status like 'all'.
Since 'all' === undefined evaluates to false, isDataLoaded gets stuck on false forever, giving us that never-ending loader.

---

💡 Recommendation

We can easily fix this by updating isSearchDataLoaded to allow status matching when the query doesn’t enforce a specific filter (essentially meaning any back-end list for that type is exactly what we need).

Here's the adjustment for isSearchDataLoaded in App/src/libs/SearchUIUtils.ts:

function isSearchDataLoaded(searchResults: SearchResults | undefined, queryJSON: SearchQueryJSON | undefined) {
    const {status} = queryJSON ?? {};

    const sortedSearchResultStatus = !Array.isArray(searchResults?.search?.status)
        ? searchResults?.search?.status?.split(',').sort().join(',')
        : searchResults?.search?.status?.sort().join(',');
    const sortedQueryJSONStatus = Array.isArray(status) ? status.sort().join(',') : status;

    // Check match or allow if query doesn't specify any limit on status
    const isStatusMatched =
        sortedSearchResultStatus === sortedQueryJSONStatus ||
        (!sortedQueryJSONStatus && (sortedSearchResultStatus === 'all' || !sortedSearchResultStatus));

    const isDataLoaded = searchResults?.data !== undefined && searchResults?.search?.type === queryJSON?.type && isStatusMatched;

    return isDataLoaded;
}

Let me know what you think of this approach! I can quickly set up a PR for this. 🚀