Spend - After resetting filters, Expenses tab is not highlighted

[applause-bot]

If you haven’t already, check out our contributing guidelines for onboarding. To join our Slack channel, fill out this form.

---

Version Number: 9.4.76-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: #96466
Email or phone of affected tester (no customers): jsdoijnodsdisojo@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Mac 26.5 / Chrome
App Component: Search

Action Performed:

Precondition:

• Have a saved search.

1. Go to staging.new.expensify.com
2. Go to Spend.
3. Open saved search.
4. Click Reset.

Expected Result:

After resetting filters, Expenses tab will be highlighted.

Actual Result:

After resetting filters, Expenses tab is not highlighted.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Screen.Recording.2026-09-10.at.9.48.55.PM.mov

View all open jobs on GitHub

Applause Internal Information
Exported by: Vincenzo Godoy
Bug ID: 7256539

[applause-bot]

While Applause doesn't embed attachments for this bug, here are the links for quick view:
https://platform.applause.com/services/links/v1/external/985ed551eeccff6c9f04f404a6e8353ce845b4fc844df3fe7e733a0e49f32110

[melvin-bot]

You have been assigned to this deploy blocker because you recently merged this PR: #96466

[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.

[melvin-bot]

@JS00001 @aimane-chnaif you have been assigned to this deploy blocker because you reviewed the offending PR: #96466

[melvin-bot]

@bernhardoj you have been assigned to this deploy blocker because you authored the offending PR: #96466

[melvin-bot]

💬 A slack conversation has been started in #expensify-open-source

[MelvinBot]

Issue Analysis

Root Cause: #96466 replaced the Spend sidebar's derived highlight with cached React state (currentSearchKey), and the Reset button never updates that cache. Reset rewrites the query to a bare type:expense (the Expenses search) via Navigation.setParams, but currentSearchKey stays pinned to saved-search-<id> — so SearchTypeMenuWide.tsx:59 (item.key === currentSearchKey) is false for Expenses and it isn't highlighted.

Recommended Fix: Roll forward, don't revert — #96466 is a 90-file refactor and this is one missing state-sync call. In useSearchFiltersBar.tsx:211-218, call resetSearchKey on the query you're about to install, mirroring the one path that already does it (useUpdateFilterQuery.tsx:55-60):

const {resetSearchKey} = useSearchQueryActions();

const resetFilters = () => {
    if (!currentSearchQueryJSON) {
        return;
    }

    const resetQuery = buildQueryStringWithResetFilters(currentSearchQueryJSON, currentDefaultSearchQueryJSON);
    resetSearchKey(buildSearchQueryJSON(resetQuery));
    Navigation.setParams({q: resetQuery, rawQuery: undefined});
    setSearchContext(false);
};

Apply the same change in the afterTransition callback at SearchAdvancedFiltersProvider.tsx:55-66 — the advanced-filters Reset has the identical bug.

⚠️ Decide the intended behavior before fixing. See the product question at the bottom of the details block — "Reset on a saved search" could reasonably mean clear everything (what the reporter expects) or restore the saved filters. The fix above is correct under either reading, but the second interpretation would resolve this report differently.

Investigation details

Confirming the causing PR

melvin-bot auto-assigned #96466 by matching the PR link Applause pasted into the "regression testing" field — a heuristic, not proof. I verified it independently against the 9.4.76 checklist (#100893): the other Search-adjacent PRs in this deploy (#97697 filter-popup perf, #99747 amount sorting, #100620 has:approved-violation, #100800 Insights nav tab) touch none of the sidebar-highlight code. Every file implicated below was modified by #96466.

Timing fits: #96466 merged 2026-09-10 13:30 UTC, reported 2026-09-11 01:53 UTC, staging-only. Production still has the old derived implementation, which is why it's unaffected.

Permalinks use 19a0a9aac19298b53803442f8085f385e4443710 (staging tip, includes the PR).

What changed

Before the PR, the highlighted item was recomputed from the current query on every render, with an explicit type:expense → expenses fallback (pre-PR useSearchTypeMenuSections.ts:152-205). activeSavedSearch was keyed on the query hash, so the instant the query moved away from a saved search, the suggested-search fallback took over.

The PR deleted that (75 lines: activeItemIndex, activeKey, activeSavedSearch) and made highlight a pure function of one state value, currentSearchKey, consumed by SearchTypeMenuWide.tsx:59, SavedSearchList.tsx:74-76, StaticSearchTypeMenu.tsx:58-62, and useActiveSavedSearch.ts:13-17.

Why Reset breaks it

currentSearchKey is useState, seeded once from the query (SearchQueryProvider.tsx:101-108). Only three things update it: an explicit sidebar press, resetSearchKey(...), or the render-phase invalidation guard (SearchQueryProvider.tsx:119-133).

The key mistake: the "default query" for a search key is looked up only in suggestedSearches. A saved search's key is saved-search-<id>, which is never in that map, so currentDefaultSearchQueryJSON === undefined for every saved search. Three things then degrade:

1. The invalidation guard no-ops. doesQueryMatchDefaultFilterKeysAndType returns true when either argument is undefined, so the else if branch never fires and resetSearchKey() is never called.
2. resetFilters mutates the query behind the state's back — it calls Navigation.setParams and never calls resetSearchKey (useSearchFiltersBar.tsx:211-218).
3. The reset query itself lands on Expenses. With no default, buildQueryStringWithResetFilters contributes zero resetFilters, keeps only keyword/groupCurrency, and falls back to currentQueryJSON.type — producing exactly the canned Expenses suggested search.

Net effect: the query becomes the Expenses search while currentSearchKey stays on the saved search. Expenses isn't highlighted, and the saved search stays highlighted despite its filters being gone.

The PR also rewrote tests/ui/components/SearchTypeMenuSavedSearchHighlightTest.tsx (+32/−70) to mock useSearchQueryContext and feed currentSearchKey in directly — so no test exercises the "saved search active, then mutate the query" transition anymore, which is precisely the broken path.

Fix ordering is safe

resetSearchKey runs synchronously before Navigation.setParams, so getSearchKeyForQuery still sees the pre-reset SEARCH_FILTERS snapshot and won't re-match the saved search via its persisted last query (that entry is only overwritten later, when the next search request fires — actions/Search.ts:1256-1266). Because the hashes differ, resetSearchKey stages the new key via setPendingCurrentSearchKey and it applies in the same commit as the new query (SearchQueryProvider.tsx:110-125) — no frame where key and query disagree.

Product question before fixing

The fix above gives the reporter what they expect. But it may not be what Reset should mean on a saved search. The alternative reading — consistent with this PR's own QA steps ("reset back to their default state… make sure it works with saved search too") and with SavedSearchList already treating item.query as the per-search baseline (SavedSearchList.tsx:158) — is that a saved search's default query is its own saved query:

const savedSearchID = searchKeyToSavedSearchID(currentSearchKey);
const currentDefaultSearchQueryString = savedSearchID
    ? savedSearches?.[savedSearchID]?.query
    : currentSearchKey
      ? suggestedSearches[currentSearchKey]?.searchQuery
      : undefined;

That fixes three symptoms at once: Reset restores the saved filters, the saved search legitimately stays highlighted, and Reset / removable X chips are correctly hidden on an unmodified saved search — which is the "why is Reset even offered here?" half of the report, caused by shouldShowResetFilters falling back to filters.length > 0 when there's no default (useSearchFiltersBar.tsx:225-226). But it resolves this report as "expectation was wrong" rather than "Expenses should highlight."

Recommendation: ship the resetSearchKey fix now — it makes the highlight follow the query unconditionally and is correct under either product answer — and track the saved-search-default-query gap as a follow-up.

---

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

---

view run · no recording available