Spend - Same saved search can be created multiple times with different name

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

1. Go to staging.new.expensify.com
2. Go to Spend > Expenses.
3. Apply any status filter.
4. Tap Save.
5. Enter name and save the search.
6. Tap Save.
7. Enter name and save the search.

Expected Result:

When the applied filter is the same, it can only be saved once.
When saving the same search again with new name, it should rename the existing search.

Actual Result:

When the applied filter is the same, it can be saved more than once.
Same saved search can be created multiple times with different name.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7256522_1789080737726.1.mp4

View all open jobs on GitHub

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

[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/b9b0ae6d7b4ac7e880b8a4d658d3b128fdb935f5cee4b7d3d5d181625fa59c7e

[melvin-bot]

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

[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

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

🔍 Investigation Summary

Classification: Frontend bug
Causing PR: #96466 - "Persist filters across view in Search" by @bernhardoj (High confidence)
Related Issues: #95976 (the issue #96466 implemented)

Recommendation: ROLL FORWARD

The melvin-bot auto-assignment was correct: #96466 changed saved-search identity from the deterministic query hash to a random rand64() ID, which silently removed the de-duplication that used to happen on save. Reverting a 90-file architectural PR (plus its already-merged backend savedSearchID support and docs follow-up #100898) is far riskier than the ~5-line fix of looking up an existing saved search with the same query before generating a new ID.

Assigned: @bernhardoj (PR author), @JS00001 and @aimane-chnaif (approving reviewers) from the causing PR — already assigned by melvin-bot.
Labels: No changes. DeployBlockerCash is kept (App-side fix required); DeployBlocker was not present.

📋 Detailed Analysis

Evidence

• Reproducible on staging (9.4.76-0), not production — so the cause is in the current deploy checklist #100893. Persist filters across view in Search #96466 is item 31 in that checklist's chronological list and is the only PR in the release that touches the saved-search create path.
• Before Persist filters across view in Search #96466, saveSearch() wrote to Onyx under the key [queryJSON.hash] and sent SaveSearch without an ID. Saving the same filter set twice therefore hit the same key and the second save just overwrote the name — i.e. exactly the "it should rename the existing search" behaviour QA expects.
• Persist filters across view in Search #96466 replaced that with a client-generated random ID, so every press of Save now mints a brand-new saved search even when the query is byte-identical.

Verification

Affected files (both modified by #96466 — confirmed via gh pr view 96466 --json files):

• src/pages/Search/SearchSavePage.tsx#L175-L177 — const id = rand64(); unconditionally, then saveSearch({id, ...}). There is no lookup against existing saved searches.
• src/libs/actions/Search.ts#L865-L904 — the diff changed the optimistic/success/failure Onyx keys from [queryJSON.hash] to [id], and the write command from {jsonQuery, newName} to {jsonQuery, savedSearchID: id, newName}.

Merge timing lines up: #96466 merged 2026-09-10 13:30 UTC, bug filed 2026-09-11 01:04 UTC against 9.4.76-0.

Root Cause

Saved searches used to be content-addressed: the Onyx key and the backend record were both derived from queryJSON.hash, which made SaveSearch an idempotent upsert — re-saving the same query renamed the existing entry.

#96466 needed stable, query-independent identifiers so per-view filter state could be persisted under a SearchKey (savedSearchIDToSearchKey(id)) even as the underlying query changes. To get that, it switched to a random rand64() ID minted at save time. That is a reasonable architectural change, but it converted the upsert into a plain insert and nothing was added to replace the implicit de-duplication, on the client or in the new savedSearchID-based write command. Result: N saves of the same filters produce N saved searches.

Suggested roll-forward fix in SearchSavePage.onSaveSearch: read ONYXKEYS.SAVED_SEARCHES, find an entry whose stored query resolves to the same hash as currentSearchQueryJSON (compare via buildSearchQueryJSON(item.query)?.hash rather than raw string equality, so formatting differences don't produce false negatives), and reuse that entry's ID instead of calling rand64(). The existing saveSearch() merge semantics then rename the existing search, matching the expected result, and setCurrentSearchKey keeps pointing at the correct key.