Expense - Expense remains on the same report after being moved to new one in offline mode.

[applause-bot]

If you haven’t already, check out our contributing guidelines for onboarding and email contributors@expensify.com to request to join our Slack channel!

---

Version Number: 9.4.32-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: #89084
Email or phone of affected tester (no customers): ibellicotest+2766@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Motorola MotoG60 / Android 12 (Hybrid app) - Windows 11 / Chrome
App Component: Money Requests

Action Performed:

Prerequisite: Account has at least one workspace.

1. Open the staging.new.expensify.com website.
2. Navigate to workspace chat.
3. Create a manual expense.
4. Open the just created expense.
5. Turn off internet connection.
6. Click on "Report" field > "Create Report"
7. Note that expense is still visible on the same report.
8. Return to chat.
9. Note that new report was created but is still empty.
10. Turn on internet connection.
11. Note that now expense is succesfully moved to new report.

Expected Result:

After moving an expense to a new report while in offline mode, it should be automatically visible on the new created report.

Actual Result:

Expense remains on the same report after being moved to a new one while in offline mode. New report is created but remains empty until recovering internet connection.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7204012_1783618086984.Move_off.mp4

View all open jobs on GitHub

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

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

[melvin-bot]

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

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

Issue Analysis

TL;DR: The auto-assignment to Guccio163 / #89084 is almost certainly wrong — that PR only touches POLICY_TAGS in requestMoney and never runs in this flow. The offline "Create Report" move fails because the optimistic Onyx write that reassigns the transaction to the new report is deferred behind a navigation-transition gate that doesn't fire reliably while offline. The regression window (prod 9.4.31-0 → staging 9.4.32-0) points at #94768 as the most likely trigger.

Root Cause (mechanism — high confidence):
When you tap Report field → Create Report on an open expense, two things happen:

1. createNewReport() fires CREATE_APP_REPORT with optimistic data → the new (empty) report appears. ✅
2. The actual move (setTransactionReport + changeTransactionsReport, which optimistically sets the transaction's reportID to the new report) is wrapped in TransitionTracker.runAfterTransitions({waitForUpcomingTransition: true, …}) inside useReportSelectionActions.ts:183-217.

That wrapper gates the optimistic move on a navigation transition starting after handleGoBack(). Offline (and especially when the RHP unmounts before the deferred callback runs), that transition doesn't register as expected, so the move callback is skipped — the transaction's reportID is never updated locally. The expense stays on the old report and the new report is empty until the queued server calls reconcile on reconnect.

The optimistic data itself is correct and has no isOffline guard — Transaction.ts:1120-1134 unconditionally sets the transaction reportID. The bug is that this code is never reached offline.

Likely regressor (medium confidence): #94768 — "Report managed card transactions to employee's default policy" (s77rt, merged 2026-07-07) is the only PR new in the 9.4.31-0 → 9.4.32-0 window that functionally restructured this flow (buildNewReportOptimisticData, usePolicyForMovingExpenses, and the createReportForPolicy guards in IOURequestStepReport.tsx). The two other in-window PRs touching these files (#95317, #95318) are pure useOnyx refactors of unrelated functions and are effectively ruled out. The underlying TransitionTracker deferral was added by #94474, but that PR is already in production 9.4.31, so it isn't the new regression on its own — #94768 likely tips over that pre-existing offline fragility.

Recommended next steps for the assignee:

1. Reassign — this is not caused by Remove Onyx.connect() usage for ONYXKEYS.COLLECTION.POLICY_TAGS in requestMoney function from src/libs/actions/IOU/TrackExpense.ts #89084. The auto-assignment matched an unrelated PR in the same deploy.
2. Reproduce offline and confirm whether the runAfterTransitions callback fires and whether changeTransactionsReport is actually invoked (log around useReportSelectionActions.ts:183-217).
3. Fastest fix candidates: run the optimistic setTransactionReport/changeTransactionsReport synchronously (or via setNavigationActionToMicrotaskQueue) instead of behind waitForUpcomingTransition: true; or revert/gate [Payment due @daledah] [No QA] Report managed card transactions to employee's default policy #94768 if a repro confirms it as the trigger.

Investigation details & evidence

Confirmed flow:

• Report field of an open expense → MONEY_REQUEST_STEP_REPORT (MoneyRequestView.tsx:1563)
• Create Report → createReportForPolicy() → createNewReport() + handleRegularReportSelection() (IOURequestStepReport.tsx:155-191)
• Deferral primitive: TransitionTracker.ts:121-159 (awaits a transition start, racing a 1000ms fallback)

Regression window: production release is 9.4.31-0; blocker is on 9.4.32-0-staging. Not reproducible in production ⇒ introduced by a PR in 9.4.31-0..9.4.32-0. Only #94768, #95317, #95318 touch the move/create-report files in that range; only #94768 is functional.

Why #89084 is a red herring: it changes MoneyRequest.ts / TrackExpense.ts / useMoneyRequestPolicyTags.ts (POLICY_TAGS in requestMoney) — none of which are on the Create-Report-move path.

Open questions worth a runtime check: is isEditing true on this path (the move only runs if (isEditing))? Does usePolicyForMovingExpenses now return a different/undefined policy for a plain workspace-chat expense post-#94768, causing createReportForPolicy to bail early? Does the buildNewReportOptimisticData if (parentReport) gate skip data the move depends on when created from a workspace chat?

---

Next Steps for Contributor+ team:
To accept: @MelvinBot implement [this](https://github.com/Expensify/App/issues/95753) to create a draft PR.
To refine: @MelvinBot <your feedback>
To reject: Explain why you are rejecting Melvin's proposal.