[Due for payment 2026-09-25] Spend - Refresh needed is displayed instead of error page when entering a failing query

[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.84-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: #100176 https://test-management.browserstack.com/projects/2219752/folder/57529521/test-cases/41237516
Email or phone of affected tester (no customers): N/A
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: MacBook Air 26.6.2 Chrome, iPhone 15 iOS 26.6.1
App Component: Search

Action Performed:

1. Navigate to the Spend page
2. Click on the Search icon
3. Enter a failing query to trigger a request error (e.g., type:chat category:abcd), enter
4. Observe the page

Expected Result:

Error page is displayed

Actual Result:

"Refresh needed. This page is out of date, refresh to see the latest" screen is displayed when searching for a failing query in Spend

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7262937_1789709022346.Refresh_needed.1.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Julia Ponikarchuk
Bug ID: 7262937

Issue Owner

Current Issue Owner: @getusha

[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/8505abf19ff925b9a2296bb269985dcfc2f3ed8b6f22b96d8c3957c57278bb13

[melvin-bot]

You have been assigned to this deploy blocker because you recently merged this PR: #100176

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

[melvin-bot]

@mountiny @getusha you have been assigned to this deploy blocker because you reviewed the offending PR: #100176

[melvin-bot]

@BartekObudzinski you have been assigned to this deploy blocker because you authored the offending PR: #100176

[melvin-bot]

💬 A slack conversation has been started in #expensify-open-source

[MelvinBot]

🔍 Investigation Summary

Classification: Frontend bug
Causing PR: fix: show a "Refresh needed" empty state for stale search results - by @BartekObudzinski (High confidence)
Related Issues: Improve the "stale search" empty state on Spend > Expenses (currently shows an error-like "Oops, something went wrong") (the issue #100176 implemented), fix: persist search response code so an invalid query keeps hiding Retry (introduced the responseJsonCode classification this PR reused)

Recommendation: REVERT

PR #100176 is a small, self-contained copy/illustration change whose only functional hunk in Search/index.tsx is the error-view block, so it reverts cleanly and restores the exact production behaviour QA expects. If @BartekObudzinski can turn it around quickly, an equally acceptable roll-forward is to gate the "Refresh needed" state on a positively identified transient failure instead of on !isInvalidQuery — see Root Cause below.

Assigned: @BartekObudzinski (PR author), @mountiny and @getusha (approving reviewers) — already assigned by Melvin, no change needed.
Labels: No changes. DeployBlockerCash is kept (the fix belongs in Expensify/App). DeployBlocker was not present, so nothing was removed.

📋 Detailed Analysis

Evidence

• The strings in the report come from fix: show a "Refresh needed" empty state for stale search results #100176. It is the PR that added search.searchResults.staleResults.title / .subtitle ("Refresh needed" / "This page is out of date, refresh to see the latest"), the FolderSync illustration, and the Refresh button.
• It is on the 9.4.84-0 checklist (Deploy Checklist: New Expensify 2026-09-17) and merged 2026-09-17 13:57 UTC, before the 9.4.84-0 staging build (2026-09-17 22:26 UTC) and ~17 hours before this report. It is not in production, which matches "Reproducible in production?: No".
• The failing step is literally step 9 of the PR's own test plan: "Run a malformed search query and verify it still shows 'Oops... Something went wrong' with no retry button." That guarantee does not hold.
• production...staging shows the error-view block in src/components/Search/index.tsx was touched by exactly one PR in this release — fix: show a "Refresh needed" empty state for stale search results #100176. The only other change to that file in the release is an unrelated bulk-action-bar spacing hunk, so the revert has no conflict.

Verification

Affected file: src/components/Search/index.tsx (the if (hasErrors) branch).

• Staging: src/components/Search/index.tsx#L1110-L1151
• Production (pre-regression): src/components/Search/index.tsx#L1106-L1139
• gh pr view 100176 --json files confirms src/components/Search/index.tsx is in the PR, along with src/components/BlockingViews/FullPageErrorView.tsx, the new simple-illustration__foldersync.svg, and the 11 src/languages/*.ts files carrying the new staleResults keys.

Root Cause

The failure classification is a binary split on a single response code, and the else side is the reassuring one.

src/components/Search/index.tsx#L1111:

const isInvalidQuery = responseStatusCode === CONST.JSON_CODE.INVALID_SEARCH_QUERY;

INVALID_SEARCH_QUERY is 401 (src/CONST/index.ts#L2680), and responseStatusCode is the code persisted on the snapshot by search() (src/libs/actions/Search.ts#L1282-L1288).

Before #100176, both branches rendered the error page — errorPage.title ("Oops... Something went wrong") with only the subtitle differing (wrongTypeSubtitle vs subtitle) and the Try again button hidden for 401. A code the server returned that wasn't 401 was still, correctly, presented as an error.

After #100176, the !isInvalidQuery branch became the "nothing is broken, just refresh" state. So every search failure whose persisted code is anything other than 401 now renders "Refresh needed", including genuine server rejections. type:chat category:abcd is one of them: the Search API rejects it with a code other than 401, so the App tells the user the page is merely out of date when the request actually failed.

Two feeder paths land in that same bucket:

1. Any non-401, non-200 response code from the Search API (e.g. EXP_ERROR/666, BAD_REQUEST/400). The existing unit tests encode this assumption — tests/ui/SearchPageTest.tsx treats EXP_ERROR as a "retryable failure" and only INVALID_SEARCH_QUERY as a real error.
2. The sentinel responseJsonCode: 0 written by failureData for a failure with no usable response code (src/libs/actions/Search.ts#L855-L858). 0 !== 401, so it also reads as "stale".

Note this is broader than the reported repro: a 500/503 from the Search API now also tells users to "refresh to see the latest".

Targeted fix, if rolling forward instead of reverting: invert the test so the friendly state requires a positive match rather than the absence of one code — for example only show "Refresh needed" when the failure produced no usable server verdict (responseStatusCode === 0, the network-level path #99352 was actually about), and let every server-returned code fall through to the errorPage copy. The hasErrors guard already excludes offline, so the reachable set is small. Whichever way it goes, the case deserves a regression test asserting that a non-401, non-0 code renders errorPage.title.

💡 Suggested AI code review rule

This bug 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: amend CONSISTENCY-6 — Proper error handling rather than add a new rule; its Condition already covers "error states are not communicated to the user clearly", but it has no case for an error that is surfaced and is simply misclassified.
• Condition: when UI copy or a UI state is selected by comparing an API jsonCode against a specific error constant (anything other than SUCCESS), the non-matching branch must be the error state. Gate a reassuring/benign state on a positive match (an allowlist of codes, or an explicit sentinel), never on the negation of one error code — otherwise every unhandled or newly added code silently inherits the reassuring copy.
• Why: fix: show a "Refresh needed" empty state for stale search results #100176 turned !(jsonCode === INVALID_SEARCH_QUERY) into "nothing is broken, just refresh", so every other server rejection — including 5xx — started telling users the page was merely out of date. That shipped to staging as this deploy blocker.
• Search pattern: grep -rnE "(jsonCode|responseJsonCode|statusCode)\s*===\s*CONST\.JSON_CODE\.(?!SUCCESS)" src/ (and the !== form), then flag any hit whose negated branch renders a non-error state.
• Offending code (❌): src/components/Search/index.tsx#L1110-L1151
• Fix (✅): the pre-regression shape, where both branches stay on the error page: src/components/Search/index.tsx#L1106-L1139

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