Refresh needed flashes briefly when clicking Try again button in error msg

[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?: No
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: Windows 11/Chrome
App Component: Search

Action Performed:

1. Navigate to staging.new.expensify.com
2. Open Spend, tap the search icon.
3. Enter type:chat category:abcd, submit.
4. Verify "Oops... Something went wrong" with "Your request could not be completed" and a Try again button.
5. Click Try again button

Expected Result:

Refresh needed error should not appear when clicking Try again button

Actual Result:

Refresh needed flashes briefly when clicking Try again button in error message

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7263406_1789752740471.Recording__44.mp4

View all open jobs on GitHub

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

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

[melvin-bot]

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

[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: #101554

[melvin-bot]

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

[melvin-bot]

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

[MelvinBot]

🔍 Investigation Summary

Classification: Frontend bug
Causing PR: [CP Staging] Search error state, distinguish stale search results from a real request failure (Expensify/App#101554) by @LukasMod (High confidence)
Related Issues: Spend - Refresh needed is displayed instead of error page when entering a failing query (the blocker #101554 was fixing), fix: show a "Refresh needed" empty state for stale search results (introduced the "Refresh needed" copy into this release)

Recommendation: ROLL FORWARD

The classification of the failure is written twice — first as the NO_RESPONSE placeholder together with the errors, then as the real response code one Onyx write later — so the "Refresh needed" variant renders for one frame before the real error copy replaces it. Reverting #101554 would reintroduce deploy blocker #101520, so a targeted fix (classify the failure once, after the outcome is known) is safer than a revert.

Assigned: @LukasMod (PR author), @mountiny and @getusha (approving reviewers) from the highest-confidence causing PR — already assigned by Melvin, no change needed.
Labels: No change. DeployBlockerCash stays (App PR caused it, App-side fix); DeployBlocker was not present, so nothing was removed.

📋 Detailed Analysis

Evidence

• #101554 merged 2026-09-18 12:39 UTC and was CP'd to staging; this bug was reported 2026-09-18 18:43 on v9.4.84-4. It is the only PR in Deploy Checklist: New Expensify 2026-09-17 that touches the Search error view (the other still-unchecked CPs — #101526 AttachmentCamera, #101528 deeplinks, #101557 description-hint revert — touch unrelated files).
• Not reproducible in production, which the code confirms: on production the Search error branch renders a single copy ("Oops… Something went wrong" + "Try again") for every non-401 failure, so there is no second variant to flash into.
• #101554 replaced the two-way isInvalidQuery branch with a three-way FAILURE_KIND split (STALE / INVALID_QUERY / FAILED) keyed on search.responseJsonCode. Once two different copies can render from two different codes for the same request, the intermediate placeholder code becomes visible.

Verification

Affected files (paths relative to the App repo, at bb99cf5):

• src/components/Search/index.tsx — L1129-L1134 maps responseStatusCode to a failure kind; NO_RESPONSE (0) ⇒ STALE ⇒ the "Refresh needed" title/subtitle/illustration. Added by #101554.
• src/libs/actions/Search.ts — L847-L863 failureData writes errors and responseJsonCode: CONST.JSON_CODE.NO_RESPONSE in the same merge.
• src/libs/actions/Search.ts — L1284-L1288 the real result.jsonCode is merged afterwards, in the .then() of makeRequestWithSideEffects.

Both files are in the PR's changed-file list (src/CONST/index.ts, src/components/Search/index.tsx, src/libs/actions/Search.ts, plus tests), and the PR diff is exactly the code quoted above.

Root Cause

Clicking Try again calls retrySearch → handleSearch → search(). The sequence of Onyx writes is:

1. optimisticData (src/libs/actions/Search.ts L810-L818) clears errors and search.responseJsonCode → loading.
2. The request fails, so failureData (L847-L863) writes errors together with the responseJsonCode: NO_RESPONSE placeholder. hasErrors is now true and useSearchLoadingState deliberately lets errors bypass the page skeleton (src/hooks/useSearchLoadingState.ts L36), so Search renders the error view immediately — with failureKind = STALE, i.e. "Refresh needed".
3. One Onyx write later the .then() at L1284-L1288 merges the real server code (non-401), failureKind becomes FAILED, and the view re-renders as "Oops… Something went wrong" + "Try again".

Step 2 → step 3 is the flash. The guard that was meant to cover this window, hasUnresolvedErrors (src/components/Search/index.tsx L396), only fires when responseStatusCode === null, and failureData never leaves it null — it always writes the 0 placeholder. It also only feeds shouldShowLoadingState, which the if (hasErrors) early return at L1111 bypasses. The same flash happens on the very first failing search; it is just easier to notice on the retry, where the error page was already on screen.

Suggested fix (roll forward)

Classify the failure once, when the outcome is actually known, and don't render the error view before it is classified:

1. src/libs/actions/Search.ts L858: drop responseJsonCode: CONST.JSON_CODE.NO_RESPONSE from failureData (keep hash/type/isLoading), so a failure never publishes a guessed classification.
2. src/libs/actions/Search.ts L1284-L1288: keep writing result.jsonCode for a real non-success code, and add the NO_RESPONSE write in the else branch (plus a .catch() on startRequest) for the case where the request genuinely produced no usable code. That is the only place where "there was no response" is actually known.
3. src/components/Search/index.tsx, just above the if (hasErrors) return at L1111: return the existing SearchRowSkeleton while hasUnresolvedErrors is true, so the single tick between the error write and the classification write holds the loading frame instead of rendering a copy that is about to change.

With (1)+(2) alone the reported scenario is fixed (the view goes straight to the real failure copy); (3) additionally prevents the mirror-image flash ("Oops…" → "Refresh needed") for an online request that ends without a response code.

If a verified fix can't land quickly, the fallback is reverting both #101554 and #100176 — reverting #101554 on its own brings back #101520.

💡 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 (.claude/skills/app-coding-standards):

• Rule: UI-4 Don't render user-visible state from a placeholder that a later write corrects
• Condition: When optimisticData/failureData writes a sentinel value (0, UNKNOWN, NONE) for a field that the same command overwrites with the authoritative value in its response handler, don't let the UI branch on that field; write the classification once, when the outcome is known, or hold the previous/loading frame until it is.
• Why: The sentinel and the real value arrive in two separate Onyx writes, so every UI branch on that field renders the wrong variant for at least one frame — here it flashed the "Refresh needed" page over the real error page (#101615).
• Search pattern: rg -n --multiline "failureData[\s\S]{0,1200}?\.then\(" src/libs/actions then, for each hit, check whether a field assigned inside failureData/optimisticData is assigned again by an Onyx.merge in the same command's .then(); cross-check consumers with rg -n "responseJsonCode|=== CONST\.[A-Z_]+\.(NO_RESPONSE|UNKNOWN|NONE)" src/components src/hooks.
• Offending code (❌): src/libs/actions/Search.ts#L847-L863 paired with src/components/Search/index.tsx#L1129-L1134
• Fix (✅): the "Suggested fix" steps above — the authoritative write at src/libs/actions/Search.ts#L1284-L1288 becomes the only place the field is classified.

The full rule file, 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.