[Due for payment 2026-08-19] Saved view header does not match the selected saved view name

[m-natarajan]

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.45-5
Reproducible in staging?: Y
Reproducible in production?: Y
If this was caught during regression testing, add the test name, ID and link from BrowserStack:
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Expensify/Expensify Issue URL:
Issue reported by: @dannymcclain
Slack conversation (hyperlinked to channel name): #Expensify Bugs

Action Performed:

1. Create or open a saved view (e.g., My Expenses).
2. Navigate to Spend > Saved.
3. Select the saved view.
4. Observe the page header.

Expected Result:

The page header should display the name of the selected saved view (e.g., My Expenses).
The header should remain consistent with the selected item in the LHN.

Actual Result:

The page header displays a generic Spend title instead of the selected saved view name.

Workaround:

Unnown

Platforms:

Select the officially supported platforms where the issue was reproduced:

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

Screenshots/Videos

Recording.3286.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022082193092208662697
• Upwork Job ID: 2082193092208662697
• Last Price Increase: 2026-07-28

Issue Owner

Current Issue Owner: @mallenexpensify

Issue Owner

Current Issue Owner: @mallenexpensify

[MelvinBot]

Proposal

What is the root cause of that problem?

When a saved view is active, the Spend page header has no code path that resolves the saved view's name, so it falls through to the generic common.spend title.

The header title is computed in SearchPageHeaderWide.tsx:20-34 purely from the activeItemIndex returned by useSearchTypeMenuSections and the matched suggested-search menu item. But when a saved search is active, useSearchTypeMenuSections.ts:144-149 deliberately returns activeItemIndex = -1. So selectedItem is undefined, the if (activeItemIndex >= 0 && selectedItem) branch is skipped, and the title stays translate('common.spend'). The header never looks up the saved search name (which lives in the savedSearches Onyx entry keyed by queryJSON.hash).

The narrow header at SearchPageHeaderNarrow.tsx:23-28 is worse — it hardcodes translate('common.spend') with no saved-search (or even type-based) branch at all.

Evidence & data flow

1. User selects a saved view in the LHN → navigates to the search root with that saved search's queryJSON, whose hash matches a key in savedSearches.
2. useSearchTypeMenuSections detects isSavedSearchActive and returns activeItemIndex = -1 (hook L144-149). Saved searches are also never pushed into typeMenuSections as menu items (the "Saved" section is created with an empty menuItems array), so there is nothing for selectedItem to resolve to.
3. The wide header sees activeItemIndex < 0, skips the title branch, and renders the generic Spend title.
4. The correct name source already exists in the LHN list — SavedSearchList.tsx:100-138 uses item.name (or a human-readable title via useSavedSearchTitles when name === query). The header just needs to replicate that lookup keyed by queryJSON.hash.

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

Make both header components resolve the saved view name from the savedSearches Onyx data before falling back to the generic title:

1. In both SearchPageHeaderWide and SearchPageHeaderNarrow, read savedSearches (via useOnyx(ONYXKEYS.SAVED_SEARCHES)) and, when savedSearches?.[queryJSON.hash] exists, use its name as the title/breadcrumbLabel instead of common.spend.
2. To match the LHN label exactly, reuse the same name resolution as SavedSearchList (item.name, or the useSavedSearchTitles-derived title when name === query) — ideally by factoring that logic into a shared helper so the header and the list can't drift.
3. Alternatively (cleaner), since useSearchTypeMenuSections already computes isSavedSearchActive, have it also return the active saved-search item/name and have the headers consume that directly.

What alternative solutions did you explore? (Optional)

Considered whether this was a suggested-search matching bug (hash mismatch against typeMenuSections), but that's not it — saved searches are intentionally excluded from the menu-item sections, so the header simply has no branch for them.

---

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

[melvin-bot]

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

[melvin-bot]

Job added to Upwork: https://www.upwork.com/jobs/~022082193092208662697

[rojiphil]

@MelvinBot

Root cause: approved.

Please refine the solution:

1. Prefer a single shared resolution path, not duplicated logic in both headers. Best option: have useSearchTypeMenuSections (or a small dedicated hook) return the active saved search item for queryJSON.hash, and have both Wide/Narrow headers consume that. Avoid stuffing saved searches into typeMenuSections.menuItems just to get an index — returning -1 for suggested-search focus is intentional.

2. Use a hash-keyed Onyx selector (same pattern as Search/index.tsx’s savedSearchSelector) rather than reading the full savedSearches map in the header components.

3. Title priority should be:
   a. active saved search display name, then
   b. existing suggested-search / type fallbacks, then
   c. common.spend.

4. For the reported case (My expenses), savedSearch.name is enough (name !== query). Do not pull the full useSavedSearchTitles dependency graph into the headers. If LHN parity for unnamed saved searches (name === query) is desired, extract a lightweight shared helper later; it is not required for this bug.

5. Update both SearchPageHeaderWide and SearchPageHeaderNarrow.

[MelvinBot]

Refined proposal

Agreed on all 5 points — here's the concrete plan.

Resolution path (points 1 & 2): Add an activeSavedSearch return value to useSearchTypeMenuSections. The hook already subscribes to SAVED_SEARCHES to build typeMenuSections, so the active item is derived from that existing subscription keyed by hash — no new full-map read is introduced in the headers, and nothing gets stuffed into menuItems (suggested-search focus stays -1). Reuse the exact DELETE-guard already in isSavedSearchActive so the two can't diverge:

const activeSavedSearch = useMemo(() => {
    if (hash === undefined || !savedSearches) {
        return undefined;
    }
    const item = savedSearches[hash];
    if (!item || (item.pendingAction === CONST.RED_BRICK_ROAD_PENDING_ACTION.DELETE && !isOffline)) {
        return undefined;
    }
    return item;
}, [savedSearches, hash, isOffline]);

Then refactor isSavedSearchActive to !!activeSavedSearch so the -1 branch and the returned item share one source of truth.

On point 2: the hook already reads the full map for section-building, so re-deriving from it there is the right place. If you'd rather the narrow header not pull the whole hook, the alternative is a tiny dedicated hook that does exactly the savedSearchSelector hash-keyed read and returns just the item + resolved title. I lean toward extending the existing hook to avoid a second SAVED_SEARCHES subscription, but happy to go the dedicated-hook route if you prefer isolation.

Single title path (points 1 & 3): The wide header already owns the a→b→c fallback chain; the narrow header currently hardcodes common.spend with no type fallbacks. To avoid duplicating that logic (and to give the narrow header the same fallbacks), extract the priority into one shared helper both headers call:

// a. active saved search display name
if (activeSavedSearch?.name) return activeSavedSearch.name;
// b. suggested-search match / type fallbacks (existing wide-header logic)
if (activeItemIndex >= 0 && selectedItem) return translate(selectedItem.translationPath);
// ...TASK / TRIP / INVOICE / CHAT type fallbacks...
// c. common.spend
return translate('common.spend');

activeSavedSearch.name is a display string, not a translation key, so it's used directly (matching the LHN, which renders item.name for the name !== query case).

Scope (point 4): For the reported "My expenses" case name !== query, so activeSavedSearch.name alone is correct — no useSavedSearchTitles dependency graph in the headers. LHN parity for unnamed saved searches (name === query, where the LHN derives a title via useSavedSearchTitles) is deferred to a later lightweight shared helper and out of scope for this bug.

Both headers (point 5): Update SearchPageHeaderWide (add the activeSavedSearch branch ahead of its existing chain) and SearchPageHeaderNarrow (call the hook + shared helper instead of the hardcoded common.spend).

---

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

[rojiphil]

@MelvinBot implement the refined proposal to create a draft PR

[MelvinBot]

🤖 Draft PR created: #97663

I implemented the refined proposal:

• useSearchTypeMenuSections now returns an activeSavedSearch derived from its existing SAVED_SEARCHES subscription (keyed by hash, with the same DELETE-guard). The old inline isSavedSearchActive check that drove the -1 branch now reuses this single source of truth so the two can't diverge — no new full-map read and nothing added to menuItems.
• A shared helper getSearchPageHeaderTitle centralizes the title priority chain both headers use: (a) active saved search's display name → (b) matched suggested-search / data-type label → (c) generic Spend. activeSavedSearch.name is used directly (display string, matching the LHN).
• SearchPageHeaderWide and SearchPageHeaderNarrow both call the hook + helper. The narrow header, which previously hardcoded common.spend with no fallbacks, now shows the saved view name and gets the same type fallbacks.

Scope: for the reported name !== query case, activeSavedSearch.name alone is correct. LHN parity for unnamed saved searches (name === query) is deferred, per the proposal.

Verified on dev NewDot (web): after selecting a saved view named "My Expenses", the header now reads "My Expenses" instead of "Spend". lint, typecheck (tsc), the React Compiler compliance check, and the related Search test suites all pass.

Please assign the reviewer and mark the PR as "Ready for review" when it's ready. Since I don't have push access to your fork, the PR branch lives on upstream — see the takeover instructions on the PR if you'd like to move it to your fork.

[rojiphil]

@MelvinBot refined proposal LGTM
🎀👀🎀 C+ reviewed

[melvin-bot]

Triggered auto assignment to @aldo-expensify, see https://stackoverflow.com/c/expensify/questions/7972 for more details.