[$250] No a report action message appeared after user move expense from report A to B

[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: 96243
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from BrowserStack: https://test-management.browserstack.com/projects/2219752/folder/13176928/test-cases/41237659
Email or phone of affected tester (no customers): lattelover1412+od16073@gmail.com
Issue reported by: Applause Internal Team
Bug source: Regression TC Execution
Device used: Web
App Component: Money Requests

Action Performed:

OldDot

1. Open the link www.staging.expensify.com >> Login as admin with workspace in OldDot
2. Create 2 reports (Report A and Report B)
3. Add one expense to "Report A"
4. Go to NewDot by clicking "Try New Expensify"

NewDot

1. Navigate to Workspace chat
2. Go to Report A >> Click on the "Report" push row
3. Select the option to move the expense to "Report B"
4. Navigate to Report B >> Open the Report B to view the details

Expected Result:

There should have a report action message displayed on report B

Actual Result:

There is no report action message is added as "moved this expense from Report A" displayed

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7209927_1784214510879.Recording__4424.mp4

View all open jobs on GitHub

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

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022077784606565282883
• Upwork Job ID: 2077784606565282883
• Last Price Increase: 2026-07-16

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

https://platform.applause.com/services/links/v1/external/b64914a45e33305831bafc40bda2a7ec89ea28827daf3e28f8c7a833ac75a279

[MelvinBot]

Proposal

What is the root cause of that problem?

When an expense is moved between reports in NewDot, the client entry point is changeTransactionsReport in src/libs/actions/Transaction.ts. The "moved this expense from Report A" system message (a MOVED_TRANSACTION report action) is built optimistically here — but it is only ever attached to the transaction thread report, never to the destination Report B's top-level chat, and it is only created at all when the source report is not open.

Two things combine to produce "no message on Report B":

1. The moved action targets the transaction thread, not Report B. The optimistic MOVED_TRANSACTION action is pushed to Onyx under ${REPORT_ACTIONS}${transactionThreadReportID} (Transaction.ts:1595-1613), and the builder hardcodes reportID: transactionThreadReportID with only a fromReportID in the original message (ReportUtils.ts:7442-7487). The top-level Report B chat only receives the IOU/money-request preview action (Transaction.ts:1436-1445).

2. A gate suppresses the action for open source reports. The action is only built in the else if (!isOpenReport(oldReport)) branch (Transaction.ts:1587-1593). If Report A is an open/draft report, movedAction stays undefined and no moved message is created anywhere.

Because this is reproducible on staging but not production, and Transaction.ts has seen heavy recent churn around the merge/move-report feature (e.g. the feat/mergeReports-action work and "fix chat - Unexpected error on opening moved report reply thread"), this looks like a recent regression in where the moved action is placed.

What changes do you think we should make in order to solve the problem?

Ensure a moved report action lands on the destination report (Report B) — not only on the transaction thread — so the "moved this expense from Report A" message is visible when the user opens Report B, matching production behavior. Concretely, in changeTransactionsReport, additionally build/attach a moved (or IOU) report action keyed on the destination reportID (Report B), and re-check the !isOpenReport(oldReport) gate so a valid move between two workspace reports isn't silently dropped.

Investigation details & open questions

• Client action: changeTransactionsReport — Transaction.ts:851
• Moved action build + gate: Transaction.ts:1587-1593, pushed to thread at Transaction.ts:1595-1613
• Builder hardcodes thread as target: ReportUtils.ts:7442-7487
• Message resolver: getMovedTransactionMessage — ReportUtils.ts:6900-6915; translation keys iou.movedTransactionFrom etc. at en.ts:1365-1368
• Backend command is CHANGE_TRANSACTIONS_REPORT (Transaction.ts:1926); the moved message text is generated client-side, so this is not primarily a backend issue.

Alternative explanation considered: the message may in fact be created on the transaction thread (nested under B) and the tester simply expected it on Report B's top-level chat. Worth confirming the intended product placement.

Open questions:

• Was source Report A an open/draft report in the repro? (determines whether the !isOpenReport gate is the exact cause)
• Product intent: should "moved this expense from A" appear on the top-level destination chat, on the transaction thread, or both?

Confidence: Medium — code paths are confirmed, but the exact mechanism (gate vs. thread-only placement) and the regressing PR aren't yet pinned down.

Possibly related: #93799 (unreported expenses can't be moved — missing IOU report action) and #95866 (error opening moved report reply thread) touch the same move-report code.

---

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

[yusufdeveloper2903]

Proposal

What is the root cause of that problem?

When an expense is moved from Report A to Report B, a report action message should be created in Report B indicating the expense was moved. The root cause is that the action that handles moving expenses likely creates a "moved" report action only in Report A (source report) but fails to create/display the corresponding action in Report B (destination report), so the recipient report never shows the "moved this expense from Report A" message.

What changes do you think we should make in order to solve the problem?

I'd look at the IOU action handler responsible for moving expenses — likely in src/libs/actions/IOU.ts. When moving an expense, we need to ensure a MOVED report action is optimistically created and added to Report B's action list.

// In the moveMoneyRequest or equivalent function in src/libs/actions/IOU.ts

+ const movedReportAction = ReportUtils.buildOptimisticMovedReportAction(
+   sourceReportID,
+   destinationReportID,
+   amount,
+   currency,
+ );

  const optimisticData = [
    // ... existing optimistic data for Report A
+   {
+     onyxMethod: Onyx.METHOD.MERGE,
+     key: `${ONYXKEYS.COLLECTION.REPORT_ACTIONS}${destinationReportID}`,
+     value: {
+       [movedReportAction.reportActionID]: movedReportAction,
+     },
+   },
  ];

This ensures Report B's action list gets the "moved this expense from Report A" message optimistically, and the server response should confirm it.

What alternative solutions did you explore?

An alternative would be to trigger a re-fetch of Report B's actions after the move completes, but that's less reliable and introduces latency — the optimistic approach above is more consistent with the existing patterns in the codebase.

[aswin-s]

Proposal

Please re-state the problem that we are trying to solve in this issue.

When a user moves an expense from Report A to Report B on Web (NewDot), and Report A is still in the OPEN state (e.g. was just created in OldDot with an expense but never submitted), opening Report B shows no "moved this expense from Report A" report action message. The expected behavior is that a MOVED_TRANSACTION report action is created describing the source report so the destination report reflects where the expense came from.

What is the root cause of that problem?

In src/libs/actions/Transaction.ts:1591, changeTransactionsReport only builds the optimistic buildOptimisticMovedTransactionAction when the source report is NOT open (!isOpenReport(oldReport)). isOpenReport in src/libs/ReportUtils.ts:1994-1996 returns true when stateNum === OPEN && statusNum === OPEN, which is exactly the state of Report A in the repro (created in OldDot, expense added, never submitted before moving). So the movedAction is never produced (line 1588 let movedAction; remains undefined), the optimistic push at line 1595-1600 is skipped, and no "moved this expense from Report A" action ever gets written to the transaction thread that Report B surfaces. The UNREPORTED branch at line 1589 also doesn't apply because the destination is a real report (Report B), not the unreported/self‑DM sentinel.

What changes do you think we should make in order to solve the problem?

1. src/libs/actions/Transaction.ts:1587-1593 — Remove the !isOpenReport(oldReport) gate for the report-to-report move case. When reportID !== CONST.REPORT.UNREPORTED_REPORT_ID and oldReportID is a real report distinct from the destination, always call buildOptimisticMovedTransactionAction(transactionThreadReportID, oldReportID) so the destination reflects the origin regardless of the source report's state.
2. Keep the existing UNREPORTED_REPORT_ID branch (line 1589-1590) that produces the UNREPORTED_TRANSACTION action — only the second branch's isOpenReport guard needs to go.
3. Verify the produced action still routes correctly: it is pushed to ${REPORT_ACTIONS}${transactionThreadReportID} (line 1598), and movedReportActionID is threaded into transactionIDToReportActionAndThreadData at line 1617 so the backend ChangeTransactionsReport command receives the same optimistic ID.
4. Add/adjust a unit test around changeTransactionsReport covering the OPEN→OPEN move case (Report A open, Report B open) to lock in that movedAction is produced.
5. Double-check the two other call sites of buildOptimisticMovedTransactionAction (src/libs/actions/IOU/TrackExpense.ts:1245, src/libs/actions/IOU/RejectMoneyRequest.ts:501) — those flows are unaffected by this repro and should remain as-is.

What alternative solutions did you explore? (Optional)

[ahmdshrif]

🚨 Edited by proposal-police: This proposal was edited at 2026-07-16 15:59:10 UTC.

Proposal

Please re-state the problem that we are trying to solve in this issue.

After moving an expense from Report A to Report B via the Report push row, no "moved this expense from Report A" system message appears on Report B. Staging-only regression (production shows the message).

What is the root cause of that problem?

This is a regression from PR #95979 (merged 2026-07-14, so it is on staging but not production — matching the repro matrix), which fixed #95866 by suppressing the optimistic MOVEDTRANSACTION action with a gate that is too broad.

1. Moving an expense between reports runs changeTransactionsReport. Step 7 builds the "moved this expense from…" action, but PR #95979 made it conditional on the source report not being open:

   App/src/libs/actions/Transaction.ts

   Lines 1587 to 1593 in 6c61fe9

   	// 7. Add MOVED_TRANSACTION or UNREPORTED_TRANSACTION report actions
   	let movedAction;
   	if (reportID === CONST.REPORT.UNREPORTED_REPORT_ID) {
   	movedAction = buildOptimisticUnreportedTransactionAction(transactionThreadReportID, oldReportID);
   	} else if (!isOpenReport(oldReport)) {
   	movedAction = buildOptimisticMovedTransactionAction(transactionThreadReportID, oldReportID);
   	}

2. In this repro, Report A is an unsubmitted (Open) report — isOpenReport(oldReport) is true (stateNum === OPEN && statusNum === OPEN):

   App/src/libs/ReportUtils.ts

   Lines 1994 to 1996 in 6c61fe9

   	function isOpenReport(report: OnyxEntry<Report>): boolean {
   	return report?.stateNum === CONST.REPORT.STATE_NUM.OPEN && report?.statusNum === CONST.REPORT.STATUS_NUM.OPEN;
   	}

   . Substituting the repro into the gate: destination is Report B (not UNREPORTED_REPORT_ID) → first branch false; !isOpenReport(oldReport) → false. So movedAction stays undefined and no optimistic action is written.
3. The same PR made movedReportActionID optional and it is now omitted from the API params (

   App/src/libs/actions/Transaction.ts

   Line 1617 in 6c61fe9

   movedReportActionID: movedAction?.reportActionID,

   ,

   App/src/libs/API/parameters/ChangeTransactionsReportParams.ts

   Line 9 in 6c61fe9

   movedReportActionID?: string;

   ), so the backend does not create the message either. The absence is total, not just optimistic — exactly what the tester sees.

Structural cause: #95866's actual bug scenario was the "Create report" flow — moving an expense out of its draft report into a brand-new optimistic report, where the backend never creates the message, so the optimistic action was orphaned and its reply thread errored. The fix keyed the suppression on the wrong discriminator: "source report is open" instead of "destination report is being created in this same action". Every ordinary move whose source happens to be unsubmitted (the most common state) lost its audit-trail message.

Affected call sites of changeTransactionsReport (all funnel through the same gate):

• Report push row while editing (this repro):

  App/src/pages/iou/request/step/IOURequestEditReport.tsx

  Line 89 in 6c61fe9

  const selectReport = (item: TransactionGroupListItem, report?: OnyxEntry<Report>) => {

• Regular report selection hook:

  App/src/pages/iou/request/step/IOURequestStepReport/hooks/useReportSelectionActions.ts

  Line 181 in 6c61fe9

  const handleRegularReportSelection = (item: TransactionGroupListItem, report: OnyxEntry<Report>) => {

• Search bulk "change report":

  App/src/pages/Search/SearchTransactionsChangeReport.tsx

  Line 233 in 6c61fe9

  const selectReport = (item: TransactionGroupListItem) => {

• Add existing expense footer:

  App/src/components/AddExistingExpenseFooter.tsx

  Line 95 in 6c61fe9

  changeTransactionsReport({

What changes do you think we should make in order to solve the problem?

Narrow the suppression to the scenario #95866 actually targeted: skip the moved message only when the expense is moving into a newly-created report. Add an optional isMovingToNewReport?: boolean to ChangeTransactionsReportProps and change the step-7 gate (

App/src/libs/actions/Transaction.ts

Lines 1587 to 1593 in 6c61fe9

	// 7. Add MOVED_TRANSACTION or UNREPORTED_TRANSACTION report actions
	let movedAction;
	if (reportID === CONST.REPORT.UNREPORTED_REPORT_ID) {
	movedAction = buildOptimisticUnreportedTransactionAction(transactionThreadReportID, oldReportID);
	} else if (!isOpenReport(oldReport)) {
	movedAction = buildOptimisticMovedTransactionAction(transactionThreadReportID, oldReportID);
	}

):

let movedAction;
if (reportID === CONST.REPORT.UNREPORTED_REPORT_ID) {
    movedAction = buildOptimisticUnreportedTransactionAction(transactionThreadReportID, oldReportID);
} else if (!(isMovingToNewReport && isOpenReport(oldReport))) {
    movedAction = buildOptimisticMovedTransactionAction(transactionThreadReportID, oldReportID);
}

Pass isMovingToNewReport: true only from the four call sites that call createNewReport and immediately move transactions into the optimistic report:

• App/src/pages/iou/request/step/IOURequestEditReport.tsx

  Lines 147 to 170 in 6c61fe9

  	const createReportForPolicy = (shouldDismissEmptyReportsConfirmation?: boolean) => {
  	if (!hasPerDiemTransactions && !hasUnreportedManagedCardTransactions && !policyForMovingExpenses?.id) {
  	return;
  	}
  	const optimisticReport = createNewReport(
  	ownerPersonalDetails,
  	hasViolations,
  	isASAPSubmitBetaEnabled,
  	policyForMovingExpenses,
  	betas,
  	isTrackIntentUser,
  	false,
  	shouldDismissEmptyReportsConfirmation,
  	);
  	selectReport(
  	{
  	value: optimisticReport.reportID,
  	keyForList: optimisticReport.reportID,
  	policyID: policyForMovingExpenses?.id,
  	},
  	optimisticReport,
  	);
  	};

  (thread a flag through selectReport)

• App/src/pages/Search/SearchTransactionsChangeReport.tsx

  Lines 147 to 161 in 6c61fe9

  	const createReportForPolicy = (shouldDismissEmptyReportsConfirmation?: boolean) => {
  	const optimisticReport = createNewReport(
  	targetOwnerPersonalDetails,
  	hasViolations,
  	isASAPSubmitBetaEnabled,
  	policyForMovingExpenses,
  	betas,
  	isTrackIntentUser,
  	false,
  	shouldDismissEmptyReportsConfirmation,
  	);
  	const reportNextStep = allReportNextSteps?.[`${ONYXKEYS.COLLECTION.NEXT_STEP}${optimisticReport.reportID}`];
  	const policyTagList = policyForMovingExpenses?.id ? allPolicyTags?.[`${ONYXKEYS.COLLECTION.POLICY_TAGS}${policyForMovingExpenses.id}`] : {};
  	setNavigationActionToMicrotaskQueue(() => {
  	changeTransactionsReport({

• App/src/pages/DynamicNewReportWorkspaceSelectionPage.tsx

  Lines 123 to 129 in 6c61fe9

  	const optimisticReport = createNewReport(policyID, shouldDismissEmptyReportsConfirmation);
  	if (isMovingExpenses && (!!selectedTransactionsKeys.length || !!selectedTransactionIDs.length)) {
  	const reportNextStep = allReportNextSteps?.[`${ONYXKEYS.COLLECTION.NEXT_STEP}${optimisticReport.reportID}`];
  	const policyTagList = policyID ? allPolicyTags?.[`${ONYXKEYS.COLLECTION.POLICY_TAGS}${policyID}`] : {};
  	setNavigationActionToMicrotaskQueue(() => {
  	changeTransactionsReport({

• App/src/pages/iou/request/step/IOURequestStepUpgrade.tsx

  Lines 135 to 141 in 6c61fe9

  	const optimisticReport = createNewReport(ownerPersonalDetails, hasViolations, isASAPSubmitBetaEnabled, newPolicy, betas, isTrackIntentUser);
  	const reportNextStep = allReportNextSteps?.[`${ONYXKEYS.COLLECTION.NEXT_STEP}${optimisticReport.reportID}`];
  	const policyTagList = policyID ? allPolicyTags?.[`${ONYXKEYS.COLLECTION.POLICY_TAGS}${policyID}`] : {};
  	// Move ALL selected transactions to the new report
  	changeTransactionsReport({

This restores the message (optimistically AND server-side, since movedReportActionID is sent again) for moves between existing reports, while #95866's repro (expense → Report → Create report) stays fixed: destination is new + source open → still suppressed. Regression safety: the UNREPORTED_TRANSACTION branch, unreported→report moves (oldReport undefined → isOpenReport false), and all four create-report flows are unchanged. Update the PR's test in tests/actions/TransactionTest.ts to cover both cases.

Why the simple fix fails: plainly reverting the gate (else { movedAction = build… }) reintroduces #95866 — in the Create-report flow the backend never adopts the client rand64() ID, the optimistic action is orphaned, and opening its reply thread calls OpenReport with a parentReportActionID the server doesn't know, writing errorFields.createChatThread. Suppression must stay for that flow; it just must key on the destination being new, not on the source being open.

What alternative solutions did you explore? (Optional)

1. Revert PR #95979 — restores this message but reintroduces the #95866 reply-thread error. Incomplete.
2. Detect the new destination inside changeTransactionsReport (e.g. !allReports[report_ + reportID]) — no call-site changes, but timing-fragile: it depends on the useOnyx snapshot not yet containing the optimistic report. The explicit flag is deterministic.
3. Keep client suppression and have the backend create the message — the message would appear only after a round trip and never offline; the App-side flag fix above works optimistically and offline.

[MobileMage]

🚨 Edited by proposal-police: This proposal was edited at 2026-07-16 16:00:20 UTC.

Proposal

Please re-state the problem that we are trying to solve in this issue.

When the user moves an expense from Report A to Report B (Report push row > select Report B), no "moved this expense from Report A" system message appears on Report B. This works in production but not on staging, so it is a regression.

What is the root cause of that problem?

This regressed in PR #95979 (commit 215eb86e328, "fix chat - Unexpected error on opening moved report reply thread", fixing #95866). That PR made changeTransactionsReport skip building the optimistic MOVED_TRANSACTION action whenever the source report is open:

App/src/libs/actions/Transaction.ts

Lines 1588 to 1592 in 6c61fe9

	let movedAction;
	if (reportID === CONST.REPORT.UNREPORTED_REPORT_ID) {
	movedAction = buildOptimisticUnreportedTransactionAction(transactionThreadReportID, oldReportID);
	} else if (!isOpenReport(oldReport)) {
	movedAction = buildOptimisticMovedTransactionAction(transactionThreadReportID, oldReportID);

if (reportID === CONST.REPORT.UNREPORTED_REPORT_ID) {
    movedAction = buildOptimisticUnreportedTransactionAction(transactionThreadReportID, oldReportID);
} else if (!isOpenReport(oldReport)) {
    movedAction = buildOptimisticMovedTransactionAction(transactionThreadReportID, oldReportID);
}

The isOpenReport(oldReport) gate is far too broad. isOpenReport is just stateNum === OPEN && statusNum === OPEN, and virtually every report an expense can be moved out of is a draft in the open state — including Report A in this repro (reports created manually in OldDot are open). So the gate suppresses the audit message for the mainline "move expense between existing reports" flow, not just for the flow #95866 targeted. The suppression is also not merely cosmetic on the client: when movedAction is undefined, movedReportActionID is omitted from transactionIDToReportActionAndThreadData in the ChangeTransactionsReport API params (the PR even changed movedReportActionID to optional in ChangeTransactionsReportParams.ts), so the backend never receives the reportActionID it uses to create the system message either. The message therefore never appears — neither optimistically nor via Pusher — which is exactly what the tester sees on Report B.

The scenario #95866 actually needed to fix is much narrower: moving an expense into a report that was just created in the same interaction (expense > Report > "Create report"), where the backend intentionally creates no "moved" message and the orphaned optimistic action (with a client rand64() ID the server never adopted) errored when its reply thread was opened. In this issue's repro both Report A and Report B are pre-existing reports, the backend does create the message for that move (which is why production, without PR #95979, shows it persistently), but the client now suppresses it and withholds the ID from the API.

What changes do you think we should make in order to solve the problem?

We should narrow the suppression from "source report is open" to the actual #95866 case: the destination report was just created optimistically in the same flow. Add an optional isMovingToNewReport?: boolean to ChangeTransactionsReportProps and use it in step 7 of changeTransactionsReport:

} else if (!(isMovingToNewReport && isOpenReport(oldReport))) {
    movedAction = buildOptimisticMovedTransactionAction(transactionThreadReportID, oldReportID);
}

Then pass isMovingToNewReport: true only from the call sites that create the target report with createNewReport right before moving: createReport in src/pages/DynamicNewReportWorkspaceSelectionPage.tsx and the createReportForPolicy path in src/pages/iou/request/step/IOURequestEditReport.tsx (its selectReport(item, report?) receives the optimistic report as the second argument only in the create flow, so isMovingToNewReport: !!report distinguishes it for free). All other callers (moving to an existing report from the Report push row, Search bulk move, AddExistingExpenseFooter) default to false and get the moved message back, and movedReportActionID is again sent to the backend so the server-created action matches the optimistic one. This preserves the #95866 fix exactly — its repro (create expense, don't submit, Report > Create report) still builds no moved action because the destination is the just-created draft and the source is open — while restoring the audit trail for genuine moves between existing reports, matching production behavior and the regression TC.

What alternative solutions did you explore? (Optional)

Reverting PR #95979 outright would restore this message but reintroduce the #95866 "Unexpected error" thread bug. We also considered detecting the just-created destination inside changeTransactionsReport via reportMetadata.isOptimisticReport instead of a new param, but the metadata write from createNewReport is queued asynchronously and may not have landed when changeTransactionsReport runs in the same tick, so an explicit caller flag is more reliable.

[abbasifaizan70]

Proposal

Please re-state the problem that we are trying to solve in this issue.

• When a user moves an expense from Report A to Report B in NewDot, no "moved this expense from Report A" system message is added to the expense's report action history on Report B, even though the expense was successfully moved.

What is the root cause of that problem?

• The optimistic report action for a moved expense is only built when the source report is not an "Open" (draft/unsubmitted) report. Report A in the repro is a freshly created report that hasn't been submitted yet, so it's in the Open state, and the code skips creating the MOVED_TRANSACTION action entirely.
  

  App/src/libs/actions/Transaction.ts

  Lines 1587 to 1593 in 6c61fe9

  	// 7. Add MOVED_TRANSACTION or UNREPORTED_TRANSACTION report actions
  	let movedAction;
  	if (reportID === CONST.REPORT.UNREPORTED_REPORT_ID) {
  	movedAction = buildOptimisticUnreportedTransactionAction(transactionThreadReportID, oldReportID);
  	} else if (!isOpenReport(oldReport)) {
  	movedAction = buildOptimisticMovedTransactionAction(transactionThreadReportID, oldReportID);
  	}

• isOpenReport is what determines this: it returns true only when both stateNum and statusNum are OPEN, i.e. exactly the state of a brand-new, unsubmitted report like Report A in this repro.
  

  App/src/libs/ReportUtils.ts

  Lines 1994 to 1996 in 6c61fe9

  	function isOpenReport(report: OnyxEntry<Report>): boolean {
  	return report?.stateNum === CONST.REPORT.STATE_NUM.OPEN && report?.statusNum === CONST.REPORT.STATUS_NUM.OPEN;
  	}

• Because movedAction ends up undefined in this case, the subsequent block that pushes the optimistic/success/failure Onyx updates for the moved action is skipped, so no report action is ever written to the transaction thread, and the user never sees a "moved this expense from Report A" message on Report B.

What changes do you think we should make in order to solve the problem?

• Always create the MOVED_TRANSACTION action when an expense is moved between two actual reports, regardless of the source report's state, so users get a system message describing the move whether the source report was a draft or already submitted.
  

  App/src/libs/actions/Transaction.ts

  Lines 1587 to 1593 in 6c61fe9

  	// 7. Add MOVED_TRANSACTION or UNREPORTED_TRANSACTION report actions
  	let movedAction;
  	if (reportID === CONST.REPORT.UNREPORTED_REPORT_ID) {
  	movedAction = buildOptimisticUnreportedTransactionAction(transactionThreadReportID, oldReportID);
  	} else if (!isOpenReport(oldReport)) {
  	movedAction = buildOptimisticMovedTransactionAction(transactionThreadReportID, oldReportID);
  	}

        let movedAction;
        if (reportID === CONST.REPORT.UNREPORTED_REPORT_ID) {
            movedAction = buildOptimisticUnreportedTransactionAction(transactionThreadReportID, oldReportID);
        } else {
            movedAction = buildOptimisticMovedTransactionAction(transactionThreadReportID, oldReportID);
        }

[samranahm]

🚫 Duplicated proposal withdrawn by 🤖 ProposalPolice.

[Abdulloh0109]

Proposal

Please re-state the problem that we are trying to solve in this issue.

After moving an expense from Report A to Report B, no "moved this expense from Report A" system message is shown, whereas regression TC 41237659 expects one.

What is the root cause of that problem?

This is not a regression — the message is being suppressed intentionally, and this TC hits exactly the case that was deliberately scoped for suppression.

In this TC, Report A is created in OldDot and the expense is moved out of it without submitting it, so Report A is still Open (stateNum: OPEN, statusNum: OPEN) — what the product surfaces as a Draft report:

App/src/libs/ReportUtils.ts

Lines 1994 to 1996 in 59a6998

	function isOpenReport(report: OnyxEntry<Report>): boolean {
	return report?.stateNum === CONST.REPORT.STATE_NUM.OPEN && report?.statusNum === CONST.REPORT.STATUS_NUM.OPEN;
	}

Step 7 of changeTransactionsReport gates the moved system message on precisely that state, so for a draft source report movedAction stays undefined and no MOVED_TRANSACTION is built:

App/src/libs/actions/Transaction.ts

Lines 1592 to 1598 in 59a6998

	// 7. Add MOVED_TRANSACTION or UNREPORTED_TRANSACTION report actions
	let movedAction;
	if (reportID === CONST.REPORT.UNREPORTED_REPORT_ID) {
	movedAction = buildOptimisticUnreportedTransactionAction(transactionThreadReportID, oldReportID);
	} else if (!isOpenReport(oldReport)) {
	movedAction = buildOptimisticMovedTransactionAction(transactionThreadReportID, oldReportID);
	}

Because movedAction is undefined, movedReportActionID is also omitted from the ChangeTransactionsReport params, so nothing is created server-side either — which is why the message never appears, even after a refresh:

App/src/libs/actions/Transaction.ts

Line 1622 in 59a6998

movedReportActionID: movedAction?.reportActionID,

That gate was added by #95979 (fix for #95866) and is intentional, not incidental:

• @mkhutornyi confirmed the product intent in [Due for payment 2026-07-30] [$250] chat-Unexpected error on opening moved report reply thread. #95866 (comment) — "Remove system messages for moving expenses when the action is taken on a Draft report. This is the expected behavior from [Slack]."
• The scope was set deliberately in [Due for payment 2026-07-30] [$250] chat-Unexpected error on opening moved report reply thread. #95866 (comment) — "Let's just fix Draft case which matches repro step in OP. The rest case (submitted, rejected, held etc) can be out of scope." (🎀 C+ reviewed)
• @NicolasBonet approved it in [Due for payment 2026-07-30] [$250] chat-Unexpected error on opening moved report reply thread. #95866 (comment).
• It is locked in by a unit test in tests/actions/TransactionTest.ts asserting no MOVED_TRANSACTION is created when an expense is moved out of a draft report, "because moves between drafts aren't part of the audit trail".

The "Reproducible in production: No" line is consistent with this: #95979 merged on Jul 14 and has only reached staging, so production still shows the old, pre-decision behavior.

What changes do you think we should make in order to solve the problem?

No App-side change. Restoring the message here would mean reverting an intentional, Slack-confirmed product decision and breaking the unit test that guards it.

The correct follow-up is to update regression TC 41237659 so that moving an expense out of a Draft report expects no moved system message, and to cover the message expectation with a source report that has been submitted instead.

One caveat worth confirming with the tester: if Report A was in fact submitted before the move, this is not the draft gate at all but the separate backend gap already flagged by @mkhutornyi in the same comment — "it looks like there's backend bug - system message isn't generated even when the action is taken on a Submitted report" — which was explicitly ruled out of scope for #95979 and needs a backend fix, not an App one. In that case this issue should be re-routed to an internal engineer rather than fixed in this repo.

What alternative solutions did you explore? (Optional)

Removing the !isOpenReport(oldReport) gate so the message is always built — rejected: it reverts the approved decision above, reintroduces #95866 (the phantom optimistic action the server never adopts, whose reply thread fails with genericCreateReportFailureMessage), and fails the existing test.