[Due for payment 2026-05-20] Spend - Search results appear after resetting filter, navigating to a different tab and back

[lanitochka17]

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.69-0
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/folder/13176922/test-cases/41237516
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 15.7.4 Chrome, iPhone 15 iOS 26.3.1
App Component: Search

Action Performed:

1. Sign in to ND
2. Create a workspace, add a couple of expenses
3. Navigate to Spend tab/ Expenses
4. In the search field type merchant:[anything with no results], apply the filter
5. Click on the expand button on filter chip, click "Reset"
6. Open Workspaces tab
7. Open Spend tab

Expected Result:

Full expenses list is displayed, filter chip does not appear on the page

Actual Result:

After resetting the filter and navigating to a different tab, then back to Spend/ Expenses, the filter and the results appear again on the page

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7148603_1778262100620.Nothing_to_show_adre_resetting_filter.mp4

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @dmkt9

[melvin-bot]

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

[OSBotify]

Investigation Summary

Classification: Frontend bug
Causing PR: Could not be identified with high confidence — see Detailed Analysis below
Related Issues: Similar to #89013 (previously fixed by #89082)

Recommendation: NEEDS INVESTIGATION

The filter chip reappearing after Reset + tab navigation is a known fragile area of the codebase. The fix in PR #89082 (module-level lastSyncedQuerySig in useSearchFilterSync) addressed the same class of bug, but the current report suggests a surviving or re-introduced edge case. The root cause requires hands-on reproduction by someone familiar with the Search filter sync mechanism.

Assigned: @wildan-m (author of PR #88246, the only staging-cycle PR that modifies useSearchFiltersBar.tsx), @joekaufmanexpensify, @dmkt9 (approvers of PR #88246)
Labels: DeployBlockerCash label kept — this is a staging-only, App-side bug affecting a core Search UX flow. No label changes made.

Detailed Analysis

Evidence

Bug Summary: After applying a merchant:[no-results] filter via the search input, expanding the filter chip's dropdown popup, and clicking Reset inside the popup, the filter chip initially disappears. However, after navigating to the Workspaces tab and returning to Spend/Expenses, the filter chip and filtered (empty) results reappear.

Platform: iOS native and Windows/Chrome (staging only, not production).

Affected code path:

1. SearchAdvancedFiltersButton calls useSearchFilterSync(queryJSON, filterFormValues) which syncs the URL-derived queryJSON into the Onyx SEARCH_ADVANCED_FILTERS_FORM key.
2. useSearchFiltersBar reads from Onyx SEARCH_ADVANCED_FILTERS_FORM to render filter chips.
3. Resetting a filter chip opens a popup (CommonPopup, TextInputPopup, etc.) and clicking Reset calls updateFilterForm({[filterKey]: undefined}) via useUpdateFilterQuery(queryJSON, true), which calls close(() => Navigation.setParams({q: updatedQueryString})).
4. useSearchFilterSync uses a module-level lastSyncedQuerySig to prevent redundant syncs on remount.

Why the filter reappears: When the user navigates back to Spend from Workspaces, the Search screen unfreezes. SearchActionsBarSwitch transitions from showStatic=true to showStatic=false (via startTransition + useFocusEffect), which remounts SearchAdvancedFiltersButton. useSearchFilterSync fires its effect. If the URL q param at this point still contains merchant:foo (because the Navigation.setParams callback was delayed, lost, or the navigation framework restored the old params on tab switch), then querySig for merchant:foo differs from lastSyncedQuerySig (which was updated to the reset value), causing updateAdvancedFilters to write the merchant filter back into Onyx — making the chip reappear.

Verification

• Affected files: src/hooks/useSearchFilterSync.ts, src/components/Search/SearchPageHeader/useSearchFiltersBar.tsx, src/components/Search/hooks/useUpdateFilterQuery.tsx
• PR Add withdrawal-status search filter #88246 (in staging) modifies useSearchFiltersBar.tsx by adding FILTER_KEYS.WITHDRAWAL_STATUS handling. It also adds a new filter that goes through the same reset code paths. While this PR is unlikely to be the direct cause, it is the only staging-cycle PR touching the search filter bar.
• The tab navigator uses freezeOnBlur: true (src/libs/Navigation/AppNavigator/Navigators/TabNavigator.tsx). When the user returns to Spend, the screen unfreezes and isHeaderInteractive transitions from false to true via startTransition, remounting SearchAdvancedFiltersButton.

Root Cause

The most probable root cause is a race condition or navigation state issue: after the user clicks Reset in the filter chip popup, the Navigation.setParams({q: defaultQuery}) call (deferred through the Modal close() callback) either races with or loses to the tab navigation, leaving the URL q param set to the old merchant:foo value. When the user returns to Spend, useSearchFilterSync sees the stale merchant:foo URL and writes it back to Onyx.

The lastSyncedQuerySig module-level variable (introduced by PR #89082) is the right mechanism but only works correctly if the URL update successfully propagates before any refocus-triggered sync.

Suggested next steps:

1. Reproduce the bug and log the value of q param when the screen regains focus after the tab switch.
2. Verify whether Navigation.setParams fires correctly after the popup Reset on iOS/Chrome.
3. Consider resetting lastSyncedQuerySig (or nullifying it) when clearAdvancedFilters or popup reset is called, so the next focus-triggered sync always re-evaluates from the URL — regardless of whether the URL update raced with navigation.