[Due for payment 2026-05-20] Spend - Filter results are not cleared after clearing cache.

[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.73-2
Reproducible in staging?: Yes
Reproducible in production?: No
If this was caught during regression testing, add the test name, ID and link from BrowserStack: https://test-management.browserstack.com/projects/2219752/test-runs/TR-28526/folder/13176923/41237531/1410970944
Email or phone of affected tester (no customers): dreamnitethedragon+vegst@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Android
App Component: User Settings

Action Performed:

1. Launch app (gmail account)
2. Go to spend
3. Enter amount:10 and search
4. Go to troubleshoot and clear data
5. Go to spend

Expected Result:

Filter results must be cleared after clearing cache.

Actual Result:

Filter results are not cleared after clearing cache.

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

[melvin-bot]

Triggered auto assignment to @JS00001 (DeployBlockerCash), see https://stackoverflowteams.com/c/expensify/questions/9980/ for more details.

[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

What is the root cause of that problem?

The search query (e.g. amount:10) is stored in React Navigation route params and in an in-memory JS dictionary (preservedNavigatorStates), neither of which are cleared by Onyx.clear().

clearOnyxAndResetApp() wipes Onyx data but never calls clearPreservedSearchNavigatorStates(), so the in-memory preserved state retains the old query.

A safety net exists — TroubleshootPage sets shouldResetSearchQuery = true before clearing — but the reset effect in Search/index.tsx is gated on hasErrors being true. After cache clear, snapshot data (and its errors) are gone, so hasErrors is false and the reset never fires.

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

Two changes are needed:

1. In clearOnyxAndResetApp(): Call clearPreservedSearchNavigatorStates() (which already exists and is exported) alongside Navigation.clearPreloadedRoutes(). This clears the in-memory preserved navigation state so SearchFullscreenRouter and SearchTabButton don't restore the stale query.

2. In Search/index.tsx: Separate the shouldResetSearchQuery branch from the hasErrors guard. When shouldResetSearchQuery is true and the route is /search, the nav params should be reset unconditionally, regardless of hasErrors.

What alternative solutions did you explore? (Optional)

• Resetting all navigation state during cache clear (e.g., navigating to HOME): This would work but is heavier than needed and could cause visual jank. Targeted clearing of just the search navigator state is more surgical.
• Only fixing the hasErrors guard: This alone isn't sufficient because SearchTabButton and SearchFullscreenRouter.getInitialState() read directly from preservedNavigatorStates before the Search component's effect even runs.

---

Next Steps for Contributor+ team: Reply with @MelvinBot implement this to create a draft PR, @MelvinBot <your feedback> to refine this analysis, or explain why you are rejecting Melvin's proposal.

[OSBotify]

Investigation Summary

Classification: Frontend bug
Causing PR: No single staging PR identified — pre-existing defect (Low confidence on any single PR)
Related Issues: None found

Recommendation: NEEDS INVESTIGATION

The root cause is a pre-existing gap in clearOnyxAndResetApp: it clears Onyx data but does not reset the in-memory preservedNavigatorStates map used by the search tab navigation. When the user navigates back to Spend after clearing cache, SearchTabButton reads the stale preserved state and restores the old search query (amount:10). A targeted fix — calling clearPreservedSearchNavigatorStates() inside clearOnyxAndResetApp — would resolve this without reverting any staging PR. The author of the TroubleshootPage / clearOnyxAndResetApp area and the SearchTabButton author should be tagged for a quick fix.

Assigned: N/A — no single causing PR identified with sufficient confidence
Labels: No label changes made. DeployBlockerCash is correct (frontend fix required in App). DeployBlocker is not present and should not be added.

Detailed Analysis

Evidence

• The bug is staging-only and reproducible on Android.
• Reproduction: search with amount:10 in Spend, clear data via Troubleshoot, navigate back to Spend — filters persist.
• All staging PRs in the current cycle were inspected. No single PR was found that changed the cache-clear or search-filter-persistence logic in a way that would introduce this regression.
• The SearchTabButton.tsx component (last changed in PR Update search groupings and suggested search names in LHN #88181, April 2026, before this staging cycle) uses getLastRoute() to restore search params from preservedNavigatorStates, an in-memory JavaScript module-level map.

Verification

Affected files:

• src/components/Navigation/NavigationTabBar/SearchTabButton.tsx — calls getLastRoute which reads preservedNavigatorStates
• src/libs/Navigation/AppNavigator/createSplitNavigator/usePreserveNavigatorState.ts — defines preservedNavigatorStates and clearPreservedSearchNavigatorStates()
• src/libs/actions/App.ts — clearOnyxAndResetApp does NOT call clearPreservedSearchNavigatorStates()

The preserved state is only cleared in Delegate.ts (lines 202 and 291), not during cache clear.

Root Cause

When clearOnyxAndResetApp() is called from TroubleshootPage:

1. Onyx is cleared (REPORT_NAVIGATION_LAST_SEARCH_QUERY and other search-related keys are wiped).
2. Navigation.clearPreloadedRoutes() is called but this only clears preloaded routes, not the preservedNavigatorStates module-level object.
3. preservedNavigatorStates still contains the SEARCH_FULLSCREEN_NAVIGATOR route with the previous q=amount:10 param.
4. When the user taps "Spend", SearchTabButton.navigateToSearch() calls getLastRoute(navigationRef.getRootState(), NAVIGATORS.SEARCH_FULLSCREEN_NAVIGATOR, SCREENS.SEARCH.ROOT).
5. getLastRoute calls getPreservedNavigatorState(lastNavigatorKey) which returns the stale state.
6. The tab button navigates to ROUTES.SEARCH_ROOT.getRoute({query: "amount:10", ...}).

Fix direction: Call clearPreservedSearchNavigatorStates() inside clearOnyxAndResetApp in src/libs/actions/App.ts. This is a targeted, low-risk fix that does not require reverting any staging PR.

There is also a setShouldResetSearchQuery(true) call in TroubleshootPage before clearOnyxAndResetApp(), which sets a React context value intended to reset the search query. However, this mechanism only fires when hasErrors is truthy in the Search component's useEffect, and after Onyx clear searchResults has no errors (it is undefined), so this reset path never executes.

[IuliiaHerets]

Xiaomi Redmi Note 10 / Android 12
App 9.3.73-4
Not repro

Screenrecorder-2026-05-13-21-59-21-698.mp4