[Due for payment 2026-08-25] Web - Spend - Report still in Workspace 1 filter after change it to another

[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.54-1
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/69228694/folder/54000753/47701683/1660994909?sort=%2Bidentifier
Email or phone of affected tester (no customers): leungbratt6+16083@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Windows 10/Chrome
App Component: Left Hand Navigation (LHN)

Action Performed:

Preconditions: User has an unvalidated account, has multiple workspaces, and has multiple reports in Workspace 1

1. Open the NewDot app
2. Navigate to the Spend - Report - Filter - Workspace 1
3. Select any report - More - Change Workspace - Select another Workspace (like Workspace 4)

Expected Result:

Report move to the new Workspace and is no longer displayed in the filter anymore, like Prod

Actual Result:

Report still exists in the current Workspace 1 filter

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7234857_1786859239548.WS.mp4

View all open jobs on GitHub

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

Issue Owner

Current Issue Owner: @QichenZhu

Issue Owner

Current Issue Owner: @BartekObudzinski

[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/946d05c5ac4c4b0bd2b3d96a12c609386c3fe241b48b0400cc659ea1624b74b3

[melvin-bot]

Triggered auto assignment to @stitesExpensify (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.

[MelvinBot]

Deploy Blocker Investigation

Most likely cause: #98558 — "reland Search re-fire fix" (reland of #98305), by BartekObudzinski. High confidence.

Recommended action: Roll forward with a targeted fix — call refreshSearchAfterReportAction from the Change Workspace flow (or broaden the non-chat re-fire check to detect changed report-level fields like policyID). A revert of #98558 works as a fallback but is worse: it was itself a reland that closed four other deploy blockers (#98494, #98502, #98543, #98544) and cut ~26% of Search API calls.

This is a frontend regression, fixable entirely within Expensify/App.

Root cause

Search rows for a non-chat query (Spend → Report → Filter: Workspace 1) are rendered from the server-computed snapshot_<hash>. Nothing re-filters that snapshot client-side, so a moved report only leaves the Workspace 1 view after a refetch from the backend.

#98558 narrowed when a non-chat search refetches. The trigger now fires only on a transaction-ID change or a displayed transaction's value/identity change:

• Re-fire condition: src/hooks/useSearchHighlightAndScroll.ts:104-111

The Change Workspace flow (changeReportPolicy) optimistically writes only report_<id>.policyID; it touches the transactions_<id> collection only when the destination workspace has a different currency:

• src/libs/actions/Report/index.ts:8083

So for the common same-currency case (Workspace 1 → Workspace 4), no transaction ID or value changes → the re-fire logic sees nothing changed → no refetch → the stale snapshot keeps showing the report under the Workspace 1 filter. Before #98305/#98558, non-chat searches refetched on essentially any report action, which is why it works in production and regresses on staging v9.4.54-1.

#98558's own description confirms the gap: move/remove-from-report are covered because they write transactions_<id>.reportID (caught by the identity check), and bulk submit got an explicit refreshSearchAfterReportAction call "because submitting touches no transaction." Change Workspace has the identical property — it touches no transaction — but was not given the same escape hatch.

The escape hatch already exists and is used for approve/pay/submit: src/libs/SearchRefreshUtils.ts:15, e.g. src/hooks/useSearchBulkActions.ts:2167.

Alternatives considered (ruled out)

• [Payment due @huult] [NO QA] Add Amount debited and Amount reimbursed filters, columns and sorting #97708 (Amount debited/reimbursed filters/columns) — additive columns; policyID still present in the whitelist and stable selector; does not alter refetch behavior.
• [Release 3] feat: Active/Archived sections + Select all in Spend workspace filter #97773 (Active/Archived sections in Spend workspace filter) — changes the filter selector UI, not how results refetch/render.
• Surface over-limit error when moving an expense to a report at the 500-transaction limit #97998 (over-limit error moving an expense) — its flow does change transactions_<id>.reportID, so Search refetches correctly.

---

💡 Suggested AI code review rule

This 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: CONSISTENCY-18 — Trigger a Search refetch when optimistically mutating report-level fields shown in Search
• Condition: An action optimistically merges a Search-displayed report-level field (e.g. policyID, statusNum, stateNum) into a ${ONYXKEYS.COLLECTION.REPORT} key without also writing the ${ONYXKEYS.COLLECTION.TRANSACTION} collection or calling refreshSearchAfterReportAction. Flag it and add the Search refresh.
• Why: The non-chat Search re-fire only reacts to transaction ID/value changes, so a report-only mutation leaves the server-computed snapshot stale (this deploy blocker). Mechanism: useSearchHighlightAndScroll.ts:104-111.
• Search pattern: In src/libs/actions/**, functions building optimisticData with key: \${ONYXKEYS.COLLECTION.REPORT}...`that mutatepolicyID/stateNum/statusNumbut have no${ONYXKEYS.COLLECTION.TRANSACTION}write and norefreshSearchAfterReportAction` reference.
• Offending code (❌): changeReportPolicy in src/libs/actions/Report/index.ts:8083
• Fix (✅): existing escape-hatch usage — useSearchBulkActions.ts:2167

If it's worth adding, a maintainer can open it as a draft PR in Expensify/App in the coding-standards skill's format.

---

Next Steps: Reply with @MelvinBot implement this to open a draft PR with the targeted fix, or @MelvinBot <feedback> to refine.