Results don't load automatically in reports after toggle off Simulate failing

[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: v9.4.84-4
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #101554
Email or phone of affected tester (no customers): kiatest.80+ck81626@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Pixel 8a/Android 16 & iPhone 16/18.7.8
App Component: Search

Action Performed:

1. Navigate to staging.new.expensify.com
2. Open debug trouble shoot modal
3. Turn on "Simulate failing network requests".
4. Open Spend, tap the search icon, enter type:expense, submit.
5. Verify the folder-and-arrows illustration, "Refresh needed", "This page is out of date, refresh to see the latest", and a Refresh button in Expenses page
6. Tap Reports tab & observe same error is displayed
7. Tap Expenses tab
8. Open debug trouble shoot modal & toggle off "Simulate failing network requests".
9. Tap Refresh & verify results load in Expenses tab
10. Switch to Reports tab

Expected Result:

After toggling off "Simulate failing network requests" & tapping Refresh button, results should automatically load when switching to Reports tab. Manual refresh is required for the results to load.

Actual Result:

After toggling off "Simulate failing network requests" & tapping Refresh button, results does not load automatically load when switching to Reports tab. Manual refresh is required for the results to load.
This happens when switching from Reports To Expenses tab as well. After toggle off & clicking refresh button, reports load as expected but when switched to expenses tab, Refresh needed message is still displayed and requires a manual refresh

Note: Issue not reproducible on Web platform

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7263444_1789755595011.az_recorder_20260918_135750.mp4

View all open jobs on GitHub

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

Issue Owner

Current Issue Owner: @FitseTLT

[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/39e63a8a8327a03f254993bb2f09f0d6194681eabf04ee0978e97e9ea3e328e1

[MelvinBot]

Proposal

What is the root cause of that problem?

Each Search tab is its own snapshot (snapshot_<hash>). When a request fails, that hash keeps errors + search.state: 'loaded' forever, and three separate guards stop the app from ever re-requesting it automatically. Only the Refresh button on that specific tab clears it — so every failed tab needs its own manual tap.

1. src/hooks/useSearchPageSetup.ts:92 bails when isSnapshotDataLoaded, and isSearchDataLoaded counts errors != null / state === 'loaded' as resolved. A failed search looks "loaded".
2. The self-heal path at useSearchPageSetup.ts:110 (which calls openSearch(undefined, hash) and is the only thing that nulls a snapshot error) is skipped because requestedHashesRef — a Set that lives for the whole page mount (:60) — already holds that hash, added at :97 when the page fired the request that failed.
3. src/components/Search/index.tsx:455 returns early on hasErrors && !shouldRefreshOnReconnect.

The reconnect escape hatch can't rescue it either: "Simulate failing network requests" never puts the app offline, because FailureTracking.ts:33 skips failure recording while the flag is on (HttpUtils.ts:142 throws after the real fetch). So prevIsOffline is never true and shouldRefreshOnReconnect at index.tsx:432 can never fire.

On "not reproducible on Web": this is narrow-vs-wide layout, not iOS-vs-web. On wide layout, switching tabs pushes a new SCREENS.SEARCH.ROOT route, remounting SearchPage with an empty requestedHashesRef — so guard 2 doesn't apply and the page self-heals. On narrow layout (every phone, and a narrow browser window) SearchTypeMenuNarrow.tsx:206-220 dispatches PUSH_PARAMS, which becomes a setParams on the same route, so SearchPage never remounts. Expect this to reproduce on web at mobile width — please update the Platforms list if it does.

This is not a regression from [CP Staging] Search error state, distinguish stale search results from a real request failure — that PR only changed the copy for this case. The stuck state existed before it, showing "Oops… Something went wrong / Try again" instead.

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

Let a stale failure (responseJsonCode === CONST.JSON_CODE.NO_RESPONSE, i.e. the request never reached the server) get one automatic retry when its tab is next opened, by resetting the current hash in requestedHashesRef on focus / hash change rather than keeping it for the whole page mount. The existing hasErrorToClear effect at useSearchPageSetup.ts:109-115 then does the rest: it clears the error, isSnapshotDataLoaded flips false, and the effect at :78 re-requests. This mirrors the isInvalidQuery exemption already at :57.

Watch the loop hazard: if the retry fails again it writes the same error, so the retry must be bounded. Keying it to focus does that naturally — :113 re-adds the hash, so at most one automatic retry per tab visit, and a second retry requires another user-driven tab switch. Do not simply drop the guard or make NO_RESPONSE non-terminal in isSearchDataLoaded; either would spin while the network is still down.

Add a UI test alongside the ones PR #101554 added in tests/ui/SearchPageTest.tsx: fail hash A and hash B, recover A, switch to B, assert a new SEARCH request fires and "Refresh needed" clears.

What alternative solutions did you explore? (Optional)

• Clear NO_RESPONSE errors on every snapshot when shouldFailAllRequests flips off. Fixes only the Troubleshoot toggle, not real network recovery. Rejected.
• Subscribe Search to a reconnect callback. Doesn't help here — the simulated-failure flag never triggers an offline→online transition, so there's nothing to hook.
• Make the wide-layout remount happen on narrow too. Fixes the symptom by accident and costs a full page remount on every tab switch. Rejected.

Confidence, and what I could not verify

High confidence on the root cause and all three guards — every line above was read at 93bcf3d, and two independent investigations converged on the same chain.

Inferred, not executed: the narrow-vs-wide navigation asymmetry is a static trace of PUSH_PARAMS → setParams (narrow) versus the NAVIGATE→PUSH rewrite in linkTo for SCREENS.SEARCH.ROOT (wide). I tried to confirm it by driving web at a 375x812 viewport, but the test session was already dead (blank page, zero accessible nodes) before the run started, so that check did not happen. Reproducing at mobile width in a browser is the cheapest way to settle it.

Possibly related: Oops... Something went wrong error message for Withdrawal status filter results touches the same Search error view but has a different trigger (a server-rejected query, not a failed request). No duplicate found.

---

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

[melvin-bot]

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