Spend - Additional filter applied in addition to saved search persists after reset app

[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): sdnsdjoisdnsoidn@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:

• Create a saved search on Spend.

1. Go to staging.new.expensify.com
2. Go to Spend.
3. Open saved search.
4. Apply a different filter.
5. Go to Account > Troubleshoot > Clear cache and restart > Reset and refresh OR relogin.
6. Go to Spend.

Expected Result:

After reset app, the saved search filters will reset to default state.

Actual Result:

After reset app, the additional filters applied on saved search filters persist even when the additional filters are not saved.
The issue also happens when user logs out and logs in.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7256523_1789080738470.2.mp4

View all open jobs on GitHub

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

[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/95ff9674ab4b2f9d4dc826899cd432cc62d4b8230fc09d58869f324815be4358

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

🔍 Investigation Summary

Classification: Frontend bug
Causing PR: #96466 - "Persist filters across view in Search" by @bernhardoj (High confidence)
Related Issues: #95976 (the CFI this PR implements), #100893 (deploy checklist)

Recommendation: DEMOTE

The persistence is the explicitly specified behavior of the CFI this PR implements: #95976 says the last query per search key — including savedSearch_* keys — is stored in a server-side searchFilters NVP, so it survives "Clear cache and restart" and re-login by design. The QA "Expected Result" here contradicts the approved spec, so this shouldn't block the deploy; there is a separate, genuine sub-bug worth a targeted roll-forward fix (details below), but it is not deploy-blocking either.

Assigned: @bernhardoj (PR author), @JS00001 and @aimane-chnaif (approving reviewers) from the highest-confidence causing PR — all three were already auto-assigned.
Labels: No changes. DeployBlockerCash is kept (an App PR caused the behavior, and the issue does not reproduce on production, so removing it is not warranted). DeployBlocker was not present. If the team agrees with DEMOTE, an internal engineer should make that call.

📋 Detailed Analysis

Evidence

PR #96466 is the only candidate. I went through every PR on the 2026-09-10 deploy checklist. The only other Search-filter-adjacent PRs are #97697 ("Perf/spend filters hover") and #99747 ("sort and total Search amounts by the sign the row displays"). Neither touches query persistence, Onyx keys, or saved searches (#97697 file list is entirely memoization/hover/scroll perf work). #96466 merged 2026-09-10 13:30 UTC, in this release, and it is the PR that introduced the entire persistence mechanism.

The mechanism was added wholesale by this PR. At the PR's base commit c31b932, src/ONYXKEYS.ts had no SEARCH_FILTERS key at all, and SearchQueryProvider.tsx did not read from Onyx. #96466 added:

• SEARCH_FILTERS: 'nvp_searchFilters' — ONYXKEYS.ts#L728
• src/types/onyx/SearchFilters.ts (new file)
• src/selectors/SearchFilters.ts (new file)

Why it survives a reset. The key is a real backend NVP, not local-only state. #95976's Technical Implementation says verbatim: "When we run Search, ensure that every query includes a searchKey in the jsonQuery, the BE will automatically save the changes to a new searchFilters nvp, so lets optimistically save the new query string in onyx." @JS00001 confirmed the server side in the PR thread: "the method to save the search to the NVP is dispatched as a job when a search is queued." The App side is just the optimistic mirror:

Search.ts#L1256-L1266 — every Search call merges the current inputQuery into nvp_searchFilters[searchKey].

nvp_searchFilters is not in KEYS_TO_PRESERVE/KEYS_TO_PRESERVE_ON_SIGN_OUT, so the local copy is wiped by Reset-and-refresh and by sign-out — it then comes straight back from the server on the next OpenApp. That is exactly the reported symptom, and it is why it reproduces identically for both "Reset and refresh" and "log out / log in".

Staging only, as expected. The NVP and the code that reads it do not exist in production yet, which is consistent with "Reproducible in production?: No".

Verification

Affected files, all modified by #96466 (file list):

File	Role
src/ONYXKEYS.ts#L728	Declares the nvp_searchFilters key (new in this PR)
src/libs/actions/Search.ts#L1256-L1266	Writes the current query into the NVP on every search
src/libs/SearchUIUtils.ts#L5033-L5045	savedSearchIDToSearchKey / getLastSearchQuery — maps a saved search to its savedSearch_<id> NVP entry
src/pages/Search/SavedSearchList.tsx#L158	LHN saved-search item navigates to the persisted last query, not item.query
src/libs/SearchQueryUtils.ts#L2678-L2699	getValidLastQuery — accepts the persisted query whenever it is a superset of the saved query's filter keys
src/components/Search/SearchQueryProvider.tsx#L69-L107	Resolves the current search key and its "default" query

Root Cause

Reproducing the reported steps against the code:

1. Opening the saved search runs Search with searchKey = savedSearch_<id>.
2. Adding an extra filter runs Search again with the same searchKey, so Search.ts#L1256 merges the modified query into nvp_searchFilters['savedSearch_<id>'], and the backend job persists it.
3. Reset/re-login clears Onyx; OpenApp returns the NVP again.
4. SavedSearchList.tsx#L158 builds the LHN item's target as getValidLastQuery(getLastSearchQuery(searchFilters, savedSearchIDToSearchKey(key)), item.query). getValidLastQuery only falls back to the saved query when the persisted query is missing a default filter key or changes type. An added filter keeps every saved filter key, so the persisted (unsaved) query wins.

So the symptom is a direct, intended consequence of storing the last query server-side. Nothing is malfunctioning relative to the spec.

The one thing here that is a real defect (worth a follow-up, not a blocker)

Saved searches have no entry in getSuggestedSearches (SearchUIUtils.ts#L784 returns only the 15 fixed suggested-search keys). So for a savedSearch_* key:

// src/components/Search/SearchQueryProvider.tsx:105
const currentDefaultSearchQueryString = currentSearchKey ? suggestedSearches[currentSearchKey]?.searchQuery : undefined;

currentDefaultSearchQueryJSON is undefined. That flows into useSearchFiltersBar.tsx#L211-L226, where resetFilters calls buildQueryStringWithResetFilters(currentSearchQueryJSON, undefined). With no default, that helper computes resetFilters from [] and strips every filter. So on a saved search, "Reset" does not restore the saved query — it dumps you on a bare type:… query.

Suggested targeted fix (roll forward), ~10 lines in SearchQueryProvider.tsx: when currentSearchKey is a savedSearch_* key, source the default query from the saved search itself instead of suggestedSearches:

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

searchKeyToSavedSearchID already exists at SearchUIUtils.ts#L5047 and savedSearches is already loaded in the provider at line 70. This makes "Reset" on a saved search snap back to the saved query, which is the recovery path for exactly the state this ticket describes. If product additionally decides that a saved search should never carry an unsaved delta across sessions, the follow-up is to skip savedSearch_* keys in the Search.ts#L1256 merge (and on the BE job) — that's a spec change to #95976, not a regression fix.

Why not REVERT

#96466 is +2748/−1006 across 90 files and also re-keys saved searches from query hash to a savedSearchID, changing the SaveSearch/DeleteSavedSearch API contracts. Reverting to fix behavior that matches the approved spec would be far riskier than the reported issue, and could strand saved searches created on staging under the new ID scheme.

cc @trjExpensify @JS00001 — could one of you confirm the product intent for saved searches specifically (should an unsaved filter delta on a named saved search persist indefinitely, as #95976 implies)? That determines whether this is DEMOTE-and-close or DEMOTE-plus-follow-up.