[Due for payment 2026-09-18] Home: "Needs approval" link opens Spend > Reports instead of the Needs approval view (multiple reports case)

[melvin-bot]

Problem

When an approver has multiple reports waiting on them, the approval link on Home takes them to the wrong place. Instead of landing on the Needs approval view, they land on Spend > Reports.

Reported on staging.

Steps to reproduce

1. Sign in as an approver with more than one report waiting for approval.
2. Go to Home.
3. Click the link/task to approve reports.

Expected result

You land on the Needs approval view with the reports waiting on you.

Actual result

You land on Spend > Reports.

Notes

With only one report to approve, the flow keeps you on Home, so this looks specific to the multi-approval case.

Reported in Slack.

Issue Owner

Current Issue Owner: @mallenexpensify

[melvin-bot]

Triggered auto assignment to Contributor-plus team member for initial proposal review - @Krishna2323 (External)

[melvin-bot]

Unable to auto-create job on Upwork. The BZ team member should create it manually for this issue.

[MelvinBot]

Proposal

What is the root cause of that problem?

The Home to-do builds the right query — it is identical to the canonical "Needs approval" search. What it fails to do is carry the search key, so the Search page keeps whatever tab it was last on.

With 2+ reports, useTodoCounts leaves singleReportIDs.approve undefined (src/hooks/useTodoCounts.ts:80-85), so Home takes the Search branch and calls Navigation.navigate(ROUTES.SEARCH_ROOT…) raw (src/pages/home/ForYouSection/index.tsx:85-93). Every other canned-Spend entry point instead goes through navigateToCannedSpendSearch, which calls setCurrentSearchKey alongside the query (src/libs/SearchNavigationUtils.ts:9-21, used at src/pages/Search/SearchTypeMenuWide.tsx:100). That is why clicking "Needs approval" in the Spend LHN works but the identical to-do on Home does not.

currentSearchKey is app-lifetime state in SearchQueryProvider (:101) and is only re-resolved when the guard at :130 decides the new query no longer matches the incumbent key's default filters. That guard is doesQueryMatchDefaultFilterKeysAndType (src/libs/SearchQueryUtils.ts:2668-2677), and its [...defaultQueryFilterKeys].every(…) is vacuously true when the incumbent default has no filters. The generic Reports search is exactly that — buildCannedSearchQuery({type: 'expense-report'}), zero filters, same type (src/libs/SearchUIUtils.ts:816-821).

So if the approver's last Spend tab was Reports, the guard passes, resetSearchKey() never fires, and the LHN stays on Spend > Reports (SearchTypeMenuWide.tsx:59). Visiting Spend > Reports once earlier in the session is enough to arm it.

Why it then sticks permanently. With the wrong key active, search() writes the approve query into nvp_searchFilters.reports (src/libs/actions/Search.ts:1255-1265). Since that NVP is server-side, getSearchKeyForQuery afterwards matches reports — declared before approve in Object.values(suggestedSearches).find(…) — even on a cold start or a direct deeplink. That matches "reproduces on staging" rather than being a one-off.

Narrow layout has a second, unconditional path to the same symptom: the static type menu only considers reports/expenses/submit and hard-falls back to Reports (src/pages/Search/SearchPageNarrow/StaticSearchTypeMenu.tsx:26-32).

Regression: #96466 ("Persist filters across view in Search", merged 2026-09-10) converted currentSearchKey from a value derived every render into sticky state behind this guard. Before it, the key was recomputed each render and always resolved to approve.

The single-report behavior is not a bug: Home opens that report in an RHP over Home (ForYouSection/index.tsx:67-76), which is what "keeps you on Home" describes.

What changes do you think we should make in order to solve the problem?

1. Use the same helper as the Spend LHN. In createNavigationHandler (ForYouSection/index.tsx:78-95), call navigateToCannedSpendSearch with the matching CONST.SEARCH.SEARCH_KEYS value instead of Navigation.navigate(ROUTES.SEARCH_ROOT…). This fixes the reported symptom and the identical latent bug in the submit, pay, and export to-dos.
2. Stop a filter-less default from being sticky. At SearchQueryProvider.tsx:130, also resetSearchKey() when the incumbent key is one of the generic typeToGenericKey values (expenses/reports) — or require the two similarSearchHashes to match when the default query has no flat filters.
3. Prefer specific keys over generic ones in getSearchKeyForQuery (:74-82), and don't let a generic key match via lastSearchFilter. Without this, already-affected accounts keep resolving to reports from their polluted NVP even after fixes 1 and 2.
4. Narrow layout: include the active suggested search in the candidate list at StaticSearchTypeMenu.tsx:26-32 rather than defaulting to Reports.

What alternative solutions did you explore? (Optional)

• Changing the query the Home to-do emits — rejected: it is already byte-identical to the suggested approve search, so there is nothing to fix there.
• Threading an explicit searchKey param through ROUTES.SEARCH_ROOT — heavier and duplicates navigateToCannedSpendSearch, which already exists for precisely this.

Supporting evidence and what I could not verify

Deterministic repro precondition: open Spend > Reports once, go to Home, then click the approve to-do with 2+ reports pending. A cold start resolves the key to expenses, so the type differs, the guard fails, and the reset does fire — which is why this looks intermittent.

Corroborating test: the vacuous-true behavior is already asserted in tests/unit/Search/SearchQueryUtilsTest.ts:4347-4351 ("returns true when the default query has no extra filter keys to satisfy").

Likely additional symptoms worth checking in the repro (predicted by the mechanism, not observed by me):

• The results list renders empty, not just mislabeled — getTodoReportsForSearchKey('reports', …) hits reportMatchesTodoBucket's default: return false in src/libs/TodosUtils.ts:168-170.
• The empty-state copy still matches on the query's similarSearchHash, so it may show the approve copy while the LHN says Reports.
• After the bug fires once, tapping Reports in the LHN loads the approve query, via getValidLastQuery accepting the polluted last query.
• src/pages/home/YourSpendSection/index.tsx:63 navigates to an awaiting-approval query the same raw way, so it likely has the same defect.

Sibling bug, always reproducible, useful as a test case: the Export to-do (ForYouSection/index.tsx:139-143) adds exportedOn: NEVER, which the suggested export search does not have. Because similarSearchHash includes the set of filter keys, it can never match and falls through to Reports 100% of the time.

Not verified: I read the code but did not run a live repro (that needs an approver with 2+ reports pending plus a prior Spend > Reports visit in-session) and did not execute a Jest probe to print the two similarSearchHash values — the identity claim rests on both call sites invoking buildQueryStringFromFilterFormValues with the same keys in the same order. I also could not confirm whether the reporter was on wide or narrow layout, which decides whether the SearchQueryProvider guard or the static menu fallback was the trigger. One direct confirmation is available: check the reporter's nvp_searchFilters — if reports.query contains action:approve to:<their accountID>, the NVP pollution is confirmed.

Confidence: Medium-high. The code path, the vacuous guard, and the missing setCurrentSearchKey are all verified by direct reading at HEAD e9e328b; the remaining uncertainty is which of the two paths the reporter hit, not whether the defect exists.

💡 Suggested AI code review rule

This looks like a recurring, mechanically detectable pattern, so it may be worth a coding-standards rule so the AI reviewer catches the next one. Proposed for Expensify/App:

• Rule: CONSISTENCY-18 — Navigate to canned Spend searches through navigateToCannedSpendSearch
• Condition: Flag any Navigation.navigate(ROUTES.SEARCH_ROOT.getRoute(…)) outside src/libs/SearchNavigationUtils.ts whose query is one of the canned/suggested searches (built by buildCannedSearchQuery or buildQueryStringFromFilterFormValues). Call navigateToCannedSpendSearch(searchKey, …) instead, so the search key travels with the query.
• Why: currentSearchKey is app-lifetime state, not derived from the URL, so navigating with only a query leaves the previous tab selected, sends the wrong searchKey to the Search backend command, and persists the mismatch into the nvp_searchFilters NVP. Motivating bug: this issue.
• Search pattern: grep -rn "ROUTES.SEARCH_ROOT.getRoute" src/ | grep -v SearchNavigationUtils — today this returns 30+ call sites, at least two of which (ForYouSection, YourSpendSection) target canned searches without setting the key.
• Offending code (❌): ForYouSection/index.tsx:85-93
• Fix (✅): SearchNavigationUtils.ts:9-21

The full rule file, with the ❌/✅ code inline in App's app-coding-standards format, would live in Expensify/App itself. If it's worth adding, a maintainer can open it there as a draft PR.

---

Next Steps for Contributor+ team:
To accept: @MelvinBot implement [this](https://github.com/Expensify/App/issues/101173) to create a draft PR.
To refine: @MelvinBot <your feedback>
To reject: Explain why you are rejecting Melvin's proposal.

---

view run · no recording available

[nkdengineer]

@MelvinBot How about this solution?

In SearchQueryProvider:

1. Match a suggested search’s default query first. Then match last filters, but skip generic keys (reports, expenses). Those already win via the type fallback, so their last filters must not steal Approve.

2. When the query still “matches” the current tab’s default filters, re-resolve anyway. If that yields a more specific key (Approve, Submit, a saved search), switch to it. Adding merchant:Amazon on Reports still stays on Reports, because that only falls back to the generic type key.

[MelvinBot]

Your step 1 is right, and it's a better fix than what I proposed. Step 2 is directionally right but needs one guardrail, or it regresses the exact merchant:Amazon case you used as your safety example.

Step 1 — correct, and it does more than you claimed

Verified: with nvp_searchFilters.reports holding an approve-shaped query, today's single-pass resolver returns reports; the two-pass version returns approve. It also self-heals already-polluted accounts, so no NVP cleanup is needed — that removes my earlier recommendation 3 entirely.

It fixes two more UI-reachable cases nobody had flagged: because expenses/reports are declared first (SearchUIUtils.ts:797, :816) and their defaults have zero filters, they also shadow statements and unapprovedCash after a user edits filters on the Expenses tab.

Two notes:

• Reuse GENERIC_SEARCH_KEYS (SearchUIUtils.ts:702) instead of a new list — it's already new Set([EXPENSES, REPORTS]) and encodes exactly "keys whose defaults constrain nothing". It's module-private today, so export it.
• Free perf win worth mentioning in the PR: today :76-77 calls getLastSearchQuery + buildSearchQueryJSON for all 15 suggested searches on every resolve. Splitting the passes skips all of that on the common path.

Your rationale about the type fallback holds — I couldn't construct a path where a generic key's stored last query is off-type, since both doesQueryMatchDefaultFilterKeysAndType and getValidLastQuery gate on type. One gap: useDeleteSavedSearch.tsx:42 is the only generic-key caller that skips getValidLastQuery. It can perpetuate a bad entry but not create one — worth tightening while you're in there.

Step 2 — add this guardrail: only switch on a canned-default or exact saved-search match, never on a lastSearchFilter match

similarSearchHash includes the values of only action and has (SearchQueryUtils.ts:653); every other filter contributes only its key. So type:expense-report merchant:Amazon and type:expense-report merchant:Zulu hash identically.

That breaks your own example. A user who once narrowed the Submit tab to merchant:Zulu has that in nvp_searchFilters.submit. Now, on Reports, they add merchant:Amazon → step 2 re-resolves → pass 2 matches submit, which is not a generic key → the tab flips to Submit. Today it correctly stays on Reports.

Restricting the switch to pass-1 (canned default) and exact saved-search hash matches eliminates this, and makes your merchant:Amazon example behave exactly as you described. The lastSearchFilter match is the right signal for initial resolution; it is the wrong signal for switching on a query edit.

Also add a test for feed coarseness

FEED is in the ignored-filters blocklist (:643-649), so hashes around Card statements are deliberately coarse. type:expense groupBy:card posted:last-statement with no feed hashes the same as the statements default, and when defaultFeedID is empty, statements and unapprovedCard hash identically. A re-resolve can switch to statements; currentDefaultSearchQueryFilterKeys then becomes {feed, posted} and the next edit fails the guard and resets — a switch-then-unswitch flip that can't happen today.

Placement

Keep the new branch as an else if after :130, inside the currentSearchHash !== prevCurrentSearchHash block. That block is React's supported adjust-state-during-render pattern and setPrevCurrentSearchHash at :120 guarantees convergence, so a third branch is safe. Hoisting the re-resolve out of that if would clobber every explicit setCurrentSearchKey (tab press, save, delete) on the next render and would break SearchQueryProvider.test.tsx:348 (pending key wins over the recompute-on-hash-change logic).

Tests

No existing test breaks, and none covers the bug — :116 already asserts the pass-1-beats-pass-2 invariant, which your change makes structural rather than accidental. Please add:

1. nvp_searchFilters.reports = the approve query, navigate to the approve query → expect approve.
2. nvp_searchFilters.expenses = the statements default → expect statements.
3. Reports + merchant:Amazon with a poisoned submit last query → expect it stays on reports.
4. The feed-coarseness case above.

Corrections to my earlier proposal

• My recommendation 2 was weaker than your step 2. I said "reset whenever the incumbent key is generic", which misses a specific→specific mismatch. Yours covers both.
• I floated approve → pay as a possible collision. It isn't. Pay's filters are {action, reimbursable, payer} (SearchUIUtils.ts:881-891), so approve's default to key is absent, the guard already fails, and that transition already works today. All of submit/approve/pay/export have distinct similarSearchHashes, cross-checked against the hardcoded values at SearchUpdateTest.ts:186 and :248.
• I over-ranked the narrow-layout fix. StaticSearchTypeMenu.getActiveKey is only a first-frame placeholder (showStatic={!isHeaderInteractive}, SearchPageNarrow/index.tsx:271), so it can flash "Reports" and then correct itself. Separate low-priority issue, not part of this fix.
• The Home call-site change is no longer load-bearing. With steps 1+2 the provider self-heals. Routing ForYouSection through navigateToCannedSpendSearch is still worth doing — it also restores the tab's persisted filters via getValidLastQuery and clears selection — but it's cleanup now, not the fix.

Two pre-existing issues to file separately

Empty-feed hash collision. When defaultFeedID is undefined or empty, the query becomes type:expense groupBy:card feed: posted:last-statement; the empty feed: value swallows the next token, so flatFilters collapses to one feed filter. Since FEED is blocklisted, its key is never added, and statements and unapprovedCard both hash to 1141398826. Pre-existing and unchanged by this proposal (declaration order picks statements), but it's the one case pass 1 can't disambiguate.

Character-seeded hash set. SearchQueryUtils.ts:633 is new Set<string>(orderedQuery), which seeds the set with the individual characters of the string rather than the string itself — almost certainly meant to be [orderedQuery]. The type/status/groupBy portion of similarSearchHash is therefore an unordered character bag, not a value comparison. It causes no collision among the 15 current defaults, but step 2 leans harder on that comparison than today's code does, so it's worth fixing first.

Verification notes. The similarSearchHash values were produced by executing the real code in Jest and cross-checked against the hardcoded values already asserted in SearchUpdateTest.ts. The feed/merchant hashing claims come from reading getQueryHashes directly. I did not run a live browser repro of the regression in step 2 — it's derived from the hashing rules plus the existing test at SearchQueryProvider.test.tsx:98, which demonstrates the same lastSearchFilter mechanism at mount time.

---

Next Steps for Contributor+ team:
To accept: @MelvinBot implement [this](https://github.com/Expensify/App/issues/101173) to create a draft PR with steps 1 and 2 plus the guardrail above.
To refine: @MelvinBot <your feedback>
To reject: Explain why you are rejecting Melvin's proposal.

---

view run · no recording available

[nkdengineer]

@MelvinBot Update your proposal and implement this.

[MelvinBot]

⏱️ Ran out of time before I could finish. This usually means the task was too complex or I got stuck exploring. Please try again with a more specific request or post in #melvinbot-ai.

Run details