[$250] No expenses displayed when sorting options clicked in To-do section

[m-natarajan]

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.3.23-3
Reproducible in staging?: Y
Reproducible in production?: Y
If this was caught during regression testing, add the test name, ID and link from BrowserStack:
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Expensify/Expensify Issue URL:
Issue reported by: @garrettmknight
Slack conversation (hyperlinked to channel name): #Migrate

Action Performed:

1. Navigate to Reports > To-do
2. Select any of the To-do options (Approve in this case)
3. Click any of the sort options (From column)

Expected Result:

Reports in view will be sorted alphabetically or by the sorting order selected by submitter

Actual Result:

Sort shows briefly, then shows no reports to approve

Workaround:

Unknown

Platforms:

Select the officially supported platforms where the issue was reproduced:

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

Screenshots/Videos

Screen.Recording.2026-02-20.at.11.31.14.AM.mov

Recording.2417.mp4

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @rojiphil

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022024856700296532499
• Upwork Job ID: 2024856700296532499
• Last Price Increase: 2026-02-20

[melvin-bot]

Triggered auto assignment to @NicMendonca (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.

[MelvinBot]

Proposal

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

When a user navigates to Reports > To-do and selects any To-do option (e.g., Approve), clicking any sort column header (e.g., "From") causes the sorted results to briefly flash and then the view becomes empty, showing no reports.

What is the root cause of that problem?

The root cause is in the isTodoSearch function in src/libs/SearchUIUtils.ts:3414-3418. This function determines whether the current search should use live Onyx data (the To-do data path) vs. API snapshot data. It compares the current search's primaryHash against the pre-computed hashes of suggested To-do searches:

function isTodoSearch(hash: number, suggestedSearches: Record<string, SearchTypeMenuItem>) {
    const TODO_KEYS: SearchKey[] = [CONST.SEARCH.SEARCH_KEYS.SUBMIT, CONST.SEARCH.SEARCH_KEYS.APPROVE, ...];
    const matchedSearchKey = Object.values(suggestedSearches).find((search) => search.hash === hash)?.key;
    return !!matchedSearchKey && TODO_KEYS.includes(matchedSearchKey);
}

The problem is that primaryHash includes sortBy and sortOrder in its computation (src/libs/SearchQueryUtils.ts:383-390), while the suggested search hashes are computed with default sort parameters (sortBy:date, sortOrder:desc). When a user changes the sort, the primaryHash changes, so search.hash === hash no longer matches, causing isTodoSearch to return false.

This triggers the following chain in src/components/Search/SearchContext.tsx:87:

shouldUseLiveData = !!currentSearchKey && isTodoSearch(currentSearchHash, suggestedSearches)

shouldUseLiveData flips from true to false, and the system falls back to reading from snapshot_{newHash} in Onyx (line 80, 109) -- which is empty/undefined because To-do searches don't normally use API snapshots.

Notably, the codebase already has a sort-independent hash called similarSearchHash (SearchQueryUtils.ts:380) which is computed before sortBy/sortOrder are appended. The searchKey in Search/index.tsx:279 correctly uses similarSearchHash to identify the To-do type. But isTodoSearch uses the wrong hash (primaryHash instead of similarSearchHash).

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

Modify isTodoSearch in src/libs/SearchUIUtils.ts:3414-3418 to compare using similarSearchHash instead of hash (primaryHash). This would make it sort-independent, matching the approach already used by searchKey resolution in src/components/Search/index.tsx:279.

Specifically:

1. Update isTodoSearch to accept and compare against similarSearchHash instead of the primary hash
2. Update the call site in src/components/Search/SearchContext.tsx:87 to pass the similarSearchHash (which would need to be tracked in the search context alongside currentSearchHash)

Alternatively, isTodoSearch could accept the already-resolved searchKey directly (which is derived from similarSearchHash in Search/index.tsx:279), avoiding the hash comparison entirely.

What alternative solutions did you explore? (Optional)

• Client-side sorting of live data: Instead of changing the hash comparison, the To-do live data could be sorted client-side based on the sortBy/sortOrder from the query. This would keep shouldUseLiveData always true for To-do searches and apply sorting locally. However, this is a larger change and the simpler hash fix addresses the root cause directly.
• Storing similarSearchHash in SearchContext: Another approach is to track currentSimilarSearchHash in SearchContext and use it for the isTodoSearch check, keeping the primary hash for snapshot subscriptions.

---

Next Steps for Contributor+ team: Reply with @MelvinBot implement this to create a draft PR, or @MelvinBot <your feedback> to refine this analysis.

[melvin-bot]

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

[melvin-bot]

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

[luacmartins]

@MelvinBot implement the solution above