Spend - User is returned to "Reports" when navigating out while on "Expenses" and returning.

[lanitochka17]

If you haven’t already, check out our contributing guidelines for onboarding and email contributors@expensify.com to request to join our Slack channel!

---

Version Number: 9.3.69-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: https://test-management.browserstack.com/projects/2219752/test-runs/TR-27460/folder/13176922/43675713/1401787070
Email or phone of affected tester (no customers): ibellicotest+2250@gmail.com
Issue reported by: Applause Internal Team
Bug source: Regression TC Execution
Device used: Motorola MotoG60 / Android 12 (Hybrid app) - Windows 11 / Chrome
App Component: Search

Action Performed:

1. Open the staging.new.expensify.com website.
2. Navigate to "Spend" > "Reports"
3. Change to "Expenses" section.
4. Return to "Inbox"
5. Navigate back to "Spend"
6. Note that you are redirected to "Spend" > "Reports" instead of landing on "Expenses" again.

Expected Result:

After returning to "Spend", user should land on the same section that was opened before navigating to a different section.

Actual Result:

After navigating out of "Spend" while on "Expenses" section and returning, user lands on "Reports" instead of "Expenses" section again.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7148519_1778256870763.Sp.mp4

View all open jobs on GitHub

[melvin-bot]

Triggered auto assignment to @JS00001 (DeployBlockerCash), see https://stackoverflowteams.com/c/expensify/questions/9980/ for more details.

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

[OSBotify]

🔍 Investigation Summary

Classification: Frontend bug
Causing PR: #88118 - "Fix navigation arrows disappearing during report browsing" by @leshniak (High confidence)
Related Issues: #87784 (the issue this PR was fixing)

Recommendation: REVERT

PR #88118 introduced a regression in search tab navigation state persistence. The fix changed how lastSearchParams is saved, causing the "Spend" tab to not remember the last active sub-section (Expenses vs Reports) when the user navigates away and returns.

Assigned: @leshniak (PR author), @adhorodyski, @aimane-chnaif, @Julesssss (approving reviewers)
Labels: DeployBlockerCash kept (frontend App PR caused the issue). No label changes made.

📋 Detailed Analysis

Evidence

• The bug is staging-only (version 9.3.69-0, not reproducible in production), which confirms it was introduced by a recent staging PR.
• PR Fix navigation arrows disappearing during report browsing #88118 merged on 2026-05-07T17:47:28Z and is included in the current staging build.
• The PR changed shouldUpdateLastSearchParams default from true to false in src/libs/actions/Search.ts and added explicit saveLastSearchParams calls in useSearchPageSetup.ts and src/components/Search/index.tsx.
• The explicit saveLastSearchParams call in useSearchPageSetup.ts is placed inside a useEffect that has an early-return guard: if (isSnapshotDataLoaded || isSnapshotSearchLoading) { return; }. This means when a user navigates from "Reports" to "Expenses" and the "Expenses" data is already cached/loaded, the effect returns early and saveLastSearchParams is never called with the "Expenses" query.
• REPORT_NAVIGATION_LAST_SEARCH_QUERY (in Onyx) therefore retains the previously saved "Reports" (type=expense-report) query.
• When the user leaves "Spend" and returns, SearchTabButton.tsx falls back to lastSearchParams from Onyx, which still holds "Reports", and navigates there instead of "Expenses".

Verification

• Affected file: src/hooks/useSearchPageSetup.ts — the saveLastSearchParams call is gated by isSnapshotDataLoaded check.
• Affected file: src/libs/actions/Search.ts — shouldUpdateLastSearchParams default changed from true to false.
• Consumer: src/components/Navigation/NavigationTabBar/SearchTabButton.tsx — reads REPORT_NAVIGATION_LAST_SEARCH_QUERY from Onyx as the fallback for tab restoration navigation.
• PR Fix navigation arrows disappearing during report browsing #88118 directly modifies all three of the above files.

Root Cause

Before PR #88118, every call to search() would implicitly call saveLastSearchParams (because shouldUpdateLastSearchParams defaulted to true). This meant that even if snapshot data was already loaded, the last search params would be updated whenever the search action fired.

PR #88118 flipped this default to false and moved the explicit save to useSearchPageSetup.ts. However, the new explicit save is inside a useEffect that short-circuits with return when isSnapshotDataLoaded || isSnapshotSearchLoading is true — exactly the case when a user switches from "Reports" to "Expenses" and the "Expenses" data was previously fetched and is still in the snapshot cache.

As a result, navigating to the "Expenses" tab no longer updates REPORT_NAVIGATION_LAST_SEARCH_QUERY in Onyx when the data is cached. When the user later returns to "Spend" from another tab, SearchTabButton reads the stale "Reports" query from Onyx and navigates to "Reports" instead of "Expenses".

The regression specifically affects the fallback path in SearchTabButton.navigateToSearch() (line 65-68): when getLastRoute cannot find the preserved navigation state (e.g. after the frozen tab's state was cleaned), it falls back to lastSearchParams?.queryJSON which still holds the stale "Reports" query.