Filters-Filter chip is still shown in Spend after tapping Reset filters

[mitarachim]

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.62-6
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/41237509
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: iPhone 15 iOS 26.3.1
App Component: Search

Action Performed:

1. Sign in to ND
2. Create a workspace
3. Enable Tags in workspace settings, add some tags
4. Create two expenses in the workspace chat - one with tag and another without a tag
5. Open Spend tab/ All Expenses
6. Tap Advanced filters icon, scroll down to Tag, select the tag from step 4, tap Save and View results
7. Tap Advanced filters again, tap Reset filters and View results

Expected Result:

The Tag chip is not displayed on the screen after resetting Advanced filters

Actual Result:

The Tag chip is still displayed on the screen after resetting Advanced filters

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7139429_1777309071869.Filters.mp4

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @borys3kk

[melvin-bot]

Triggered auto assignment to @lakchote (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: #86297 - "[Wiring the UI] Revamp search page actions bar" by @bernhardoj (Medium confidence)
Related Issues: N/A

Recommendation: NEEDS INVESTIGATION

The root cause points to the revamped search actions bar (PR #86297) which restructured how useSearchFilterSync and the filter chip bar work, but the exact code path causing the tag chip to persist on iOS after reset could not be definitively confirmed through static analysis alone. The PR author and reviewers should investigate and either revert or roll forward with a targeted fix.

Assigned: @bernhardoj (PR author), @JS00001 (approving reviewer), @luacmartins (approving reviewer) from highest-confidence causing PR only
Labels: Removed DeployBlocker (backend label) — this is a pure frontend/App bug. Keeping DeployBlockerCash.

Detailed Analysis

Evidence

• The bug is iOS-only (narrow layout), which is characteristic of navigation focus/unfocus behavior differences on iOS vs. Android/web.
• The bug involves the Tag filter chip persisting in the Spend tab after tapping Reset filters and then View results in the Advanced Filters page.
• PR [Wiring the UI] Revamp search page actions bar #86297 ("Wiring the UI — Revamp search page actions bar", merged 2026-04-15) made sweeping changes to useSearchFiltersBar.tsx (+251/-577 lines), moved useSearchFilterSync from SearchPage.tsx to SearchAdvancedFiltersButton, restructured the filter chip bar in SearchFiltersBarNarrow, and restructured how SearchAdvancedFiltersButton operates.
• These changes fundamentally altered the interaction between the filter form Onyx state, the URL-derived queryJSON, and the useSearchFilterSync hook that syncs them.

Verification

• Affected files: src/hooks/useSearchFilterSync.ts, src/components/Search/SearchPageHeader/SearchAdvancedFiltersButton.tsx, src/components/Search/SearchPageHeader/useSearchFiltersBar.tsx, src/pages/Search/SearchAdvancedFiltersPage.tsx
• PR [Wiring the UI] Revamp search page actions bar #86297 modifies all of these files.
• The chip bar reads from ONYXKEYS.FORMS.SEARCH_ADVANCED_FILTERS_FORM via useSearchFiltersBar. The clearAdvancedFilters() action (triggered by "Reset filters") sets tag: null via Onyx.merge. This should prevent the chip from showing.

Root Cause (Hypothesized)

The useSearchFilterSync hook in SearchAdvancedFiltersButton has an isFocused guard (!wasPreviouslyFocused) that correctly skips the first sync when the Search page regains focus after returning from Advanced Filters. However, on iOS (narrow layout), there is a timing window during the navigation transition where:

1. The Search page regains focus (guard fires, skips sync — correct behavior).
2. The OLD queryJSON (containing tag: [X]) may still be active because the navigation state hasn't fully updated to reflect the new URL from applyFiltersAndNavigate.
3. Any subsequent re-render within that window causes useSearchFilterSync to fire again with isFocused=true and wasPreviouslyFocused=true, which calls updateAdvancedFilters({tag: [X]}, true) using Onyx.set, restoring the tag value that clearAdvancedFilters had just cleared.

This is an iOS-specific race condition between navigation state settling and Onyx form state. The revamp in PR #86297 changed the location and timing of the sync, potentially exposing this race.

Alternative Candidate

PR #87079 ("Fix date filter reset not persisting cleared values to Onyx", merged 2026-04-21) fixed a similar stale-value restoration pattern for date filters using DatePresetFilterBase. If the tag filter has a comparable sync effect elsewhere in the component tree, this PR might not have covered it. (Low confidence this is the primary cause — PR #87079 only touches date filter components.)