Spend - Submit, Hold and Move to report option are missing after moving expense to report

[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.53-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/68879246/folder/52646791/41237099/1653442604?sort=-identifier
Email or phone of affected tester (no customers): sdoinjsodjidosjiosjoj@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Mac 26.5 / Chrome
App Component: Money Requests

Action Performed:

1. Go to staging.new.expensify.com
2. Go to workspace chat.
3. Create an expense.
4. Go to Spend > Expenses.
5. Select the expense via checkbox.
6. Click dropdown button > Move expense.
7. Click Create report.
8. Select the expense via checkbox.
9. Click dropdown button.

Expected Result:

Submit, Hold and Move to report option will be present.

Actual Result:

Submit, Hold and Move to report option are missing after moving expense to report.

The options are only shown after reopening Spend > Expenses.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7232057_1786564768935.5.mp4

View all open jobs on GitHub

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

[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/595b4d0e1b868a6eeef0594f020aefa76a70abb95b3ea69e1b363ce3184fa181

[melvin-bot]

Triggered auto assignment to @MonilBhavsar (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]

🔍 Investigation Summary

Classification: Frontend bug
Causing PR: #95902 - "fix: Preserve all matching selection after deselecting an expense" by @emkhalid (Medium confidence)
Related Issues: none

Recommendation: REVERT

This PR rewrote the entire Search selection machinery (SearchSelectionProvider, SearchWriteActionsProvider, useSearchBulkActions, Search.ts), replacing the old isRefreshingSelection refresh with a reconcile effect. The bug's symptom — the per-transaction bulk-action metadata staying stale until a fresh server search — matches a regression in that new refresh path, and it is the only selection-system change in this deploy that isn't in production. If a clean revert is complicated by dependent selection PRs, roll forward with a targeted fix that re-derives the selected transaction's action / canHold / canChangeReport after a move-to-report action instead.

Assigned: @emkhalid (PR author), @Valforte, @mkhutornyi (approving reviewers) from the highest-confidence causing PR
Labels: No change. Only DeployBlockerCash is present; this is a Frontend bug so the App deploy remains blocked. (DeployBlocker/Web label is not present, so nothing to remove.)

📋 Detailed Analysis

Evidence

• The three missing options in the Spend › Expenses bulk dropdown are each gated purely on the selected-transaction metadata, not on live data:
  • Submit → every selected transaction's action === SUBMIT (useSearchBulkActions.ts#L2073-L2084)
  • Hold → every selected transaction's canHold (useSearchBulkActions.ts#L2216-L2218)
  • Move to report → every selected transaction's canChangeReport (useSearchBulkActions.ts#L2339-L2347)
• These three fields are all produced by mapTransactionItemToSelectedEntry, which derives them from the search snapshot item (item.action, item.report, item.reportAction) at selection/reconcile time (selectionBuilders.ts#L54-L97). If that metadata reflects the pre-move (unreported) state, all three options vanish together — exactly the reported symptom.
• The options reappear only after reopening Spend › Expenses, i.e. after a fresh server search repopulates the snapshot with the new report context. That "stale until re-fetch" behavior is a selection-refresh problem, not a backend error.
• PR fix: Preserve all matching selection after deselecting an expense #95902 (merged 2026-08-11, in the 9.4.53 staging checklist, not in production 9.4.52) is the single change in this deploy that reworked this exact system. It replaced the former isRefreshingSelection flag with a reconcile effect and changed how the selected-transaction entries are built and refreshed.

Verification

• Affected files confirmed touched by fix: Preserve all matching selection after deselecting an expense #95902: src/components/Search/SearchSelectionProvider.tsx, src/components/Search/SearchWriteActionsProvider.tsx, src/hooks/useSearchBulkActions.ts, src/components/Search/selectionBuilders.ts (via its callers), and src/libs/actions/Search.ts.
• The reconcile effect that is supposed to refresh selected-transaction metadata when the underlying data changes intentionally omits selectedTransactions/excludedTransactions from its dependency array and reads them from closure (SearchWriteActionsProvider.tsx#L318-L330); the design note about replacing isRefreshingSelection is at SearchSelectionProvider.tsx#L82-L88. This is the plausible mechanism by which the moved transaction's entry is not refreshed to the new report context.
• Reproducible on staging (9.4.53-0), not on production (9.4.52) — consistent with a regression from a PR that is on staging only.

Root Cause

After moving an unreported expense to a newly-created report from Search, the selected transaction's cached metadata (action, canHold, canChangeReport) continues to reflect the pre-move unreported state. Because Submit/Hold/Move to report are each gated on that cached metadata, none of them render until a fresh server search rebuilds the snapshot. The selection-refresh/reconcile rework in #95902 is the most likely origin of the stale metadata. A secondary suspect, #97227 (hold/reject builders), only touches the Hold/Reject gating and cannot by itself explain Submit and Move to report also disappearing, so it is ranked lower.