[Due for payment 2026-07-30] Spend - Unable to return to "Expenses" section after saving a search.

[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.45-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: #96443
Email or phone of affected tester (no customers): ibellicotest+2766@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Motorola MotoG60 / Android 12 (Hybrid app) - Windows 11 / Chrome
App Component: Search

Action Performed:

1. Open the Expensify app.
2. Navigate to "Spend" > "Expenses"
3. Tap on the "Save" button.
4. Enter any name > "Save View"
5. Once you land on the saved search, tap on "Expenses"
6. Note that no action is triggered and you remain on the saved search.

Expected Result:

User should be able to navigate through every "Spend" tab after saving a search.

Actual Result:

User is unable to return to "Expenses" tab after saving a search.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7219213_1785187103148.Saved_Spend.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Svetlana Lazutkina
Bug ID: 7219213

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022081863436757713661
• Upwork Job ID: 2081863436757713661
• Last Price Increase: 2026-07-27

Issue Owner

Current Issue Owner: @mallenexpensify

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

[MelvinBot]

Proposal

What is the root cause of that problem?

On the narrow (Android) menu, the "Expenses" Spend tab is being treated as the active tab while a saved search is displayed, and the active-tab handler intentionally does not navigate — so the tap does nothing.

Two pieces combine:

1. Active-tab detection has a type-based fallback. In useSearchTypeMenuSections.ts:144-183, if the current view is not recognized as an active saved search and no exact match is found, a fallback maps any type:expense view to the Expenses key (L165-L180). This marks the Expenses tab active even though you're sitting on a saved search.

2. The active-tab handler never navigates. SearchTypeMenuNarrow.tsx handleActiveTabPress (L203-L210) only closes the menu and clears search context — it has no navigation.dispatch. Because TabSelectorBase routes taps on the active tab to onActiveTabPress (L106-L113), the Expenses tap hits handleActiveTabPress and the user stays put. Only handleTabPress (L212-L225) actually navigates.

The trigger is that isSavedSearchActive (L145) returns false for the search you just saved (it should return -1/no active tab). saveSearch stores the entry keyed by queryJSON.hash, so this is most likely a hash mismatch between the saved-search key and the re-derived hash of the view you land on after saving. When that check fails, the type:expense fallback fires and Expenses is wrongly marked active.

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

Make tapping a Spend tab always land on that tab's canned search, even when the menu thinks it is already active while a saved search is showing. Preferred, targeted fix:

• Fix the active-search detection so a saved search is correctly recognized (isSavedSearchActive, L145), so activeItemIndex returns -1 for it and the type:expense fallback (L165-L180) doesn't misfire. This keeps the Expenses tab correctly non-active while on a saved search, so the tap flows through handleTabPress and navigates.

As a defensive fallback, handleActiveTabPress could navigate to the canned search when the current view isn't actually that canned search (re-navigating to a tab you're genuinely already on is a harmless no-op).

What alternative solutions did you explore? (Optional)

Confirm the exact trigger on Android staging by comparing the SearchRoot's queryJSON.hash right after "Save View" against the key written to SAVED_SEARCHES by saveSearch (L768-L808). If they differ, the fix belongs in hash normalization / isSavedSearchActive; if they match, it's a transient render before savedSearches updates and the fix should guard the fallback.

Confidence & notes

• Confidence: Medium. The navigation-suppression mechanism (fallback marks Expenses active → handleActiveTabPress doesn't navigate) is verified at file:line. The exact reason isSavedSearchActive returns false for the just-saved search needs runtime confirmation.
• This is a client-side App issue (Search feature); no backend change needed.
• Regression testing referenced PR Add Spend navigation suggestions to Search Router #96443 ("Add Spend navigation suggestions to Search Router"). That PR's edits to the two menu files were an icon-list refactor and a wide-menu navigate extraction — it did not change the narrow-menu tab handlers or useSearchTypeMenuSections. The suppression path lives in the files above, independent of that PR's menu edits.
• Possibly related: [CFI] [$250] Add navigation suggestions in Search Router #92752 (the Search Router navigation-suggestions feature this area was recently refactored for) and [$250] Saved search-Total spend is not shown right after saving the search results #96419 (a saved-search bug in the same surface). Neither looks like a duplicate.

---

Next Steps for Contributor+ team:
To accept: @MelvinBot implement [this](https://github.com/Expensify/App/issues/97161) 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 - @abzokhattab (External)

[melvin-bot]

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

[trjExpensify]

@nabi-ebrahimi @marufsharifi @carlosmiceli is this actually from #96443? If so, why isn't it a blocker?

[nabi-ebrahimi]

@trjExpensify @marufsharifi @carlosmiceli I reproduced this on the latest main and reviewed the failure path. It is not introduced by #96443: that PR added Spend suggestions to Search Router, while this issue comes from the existing narrow Spend menu treating Expenses as active after saving a search and therefore skipping navigation when it is pressed.

repro-main.mp4

This should be handled separately from #96443. If helpful, I can investigate the exact active-tab mismatch and open a focused PR for #97161.

[nabi-ebrahimi]

@trjExpensify @marufsharifi @carlosmiceli I tested this on the latest main after locally reverting all changes from #96443, and the issue is still reproducible. This confirms it was not introduced by our Spend navigation changes.

repro-main.mp4

The issue comes from the existing narrow Spend menu treating Expenses as active after saving a search and therefore skipping navigation when it is pressed. It should be handled separately from #96443. If helpful, I can investigate further and open a focused PR for #97161.

[carlosmiceli]

@trjExpensify do you know who I can tag from QA so we can learn more about why this didn't show up in previous tests if it was broken already? So many bots... 😅

@nabi-ebrahimi yes, prioritizing a fix for this would be great if it was already broken on main before, do you think this could be prioritized?

[nabi-ebrahimi]

@carlosmiceli yes, could please assign me, i will open a pr to fix this asap. thanks.