[$250] The header shows the hold message after marking the held expense as done

[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: v9.3.82-3
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #88455
Email or phone of affected tester (no customers): n/a
Issue reported by: Applause Internal Team
Bug source: Pull Request QA execution
Device used: Mac 15.4.1 Safari/Chrome, iPhone 13 iOS 26.5
App Component: Chat Report View

Action Performed:

Pre-condition: Login new gmail account and select Track expenses for my business during onboarding

1. Go to https://staging.new.expensify.com
2. Open workspace chat
3. Create a track distance manual expense
4. Long press preview and select hold
5. Hold the expense entering a reason
6. Tap more - Submit

Expected Result:

After marking the held expense as done, the header must not show the hold message and the LHN would reflect the correct latest status ('marked as done')

Actual Result:

The header shows the hold message after marking the held expense as done

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7163933_1779848554770.Recording__2286.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Mita Rachim
Bug ID: 7163933

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022059476629104425841
• Upwork Job ID: 2059476629104425841
• Last Price Increase: 2026-05-27

[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/0d98197ff1f2b7e012ded39a24cf566d0ec56961ba9e803ecfa562deef9e33af

[MelvinBot]

Proposal

What is the root cause of that problem?

When "Mark as done" runs, it calls submitReport() which sets the report's statusNum to CLOSED — but it never clears transaction.comment.hold on held transactions. The hold banner in useMoneyReportHeaderStatusBar.ts:104-105 checks only hasOnlyHeldExpenses (which reads transaction.comment.hold) with no guard for whether the report is already closed/done.

By contrast, the approve flow in ReportWorkflow.ts:646-668 does clear holds optimistically, but the submit flow in ReportWorkflow.ts:1386-1404 only updates report-level fields and never touches transaction holds.

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

In submitReport() in ReportWorkflow.ts, when the policy uses submit-and-close (i.e., the report goes straight to CLOSED), add optimistic data to clear transaction.comment.hold on all held transactions — mirroring the same pattern used in approveMoneyRequest at lines 646-668.

This ensures the hold banner disappears immediately upon "Mark as done" without waiting for the server response.

What alternative solutions did you explore? (Optional)

An alternative would be to add a report-status guard in useMoneyReportHeaderStatusBar.ts:104 to suppress the ON_HOLD banner when the report is closed (using isClosedReport()). However, this only hides the symptom at the UI layer — the recommended fix clears the hold at the data layer during submit-and-close, which is consistent with how the approve flow already handles it.

Investigation details

Data flow:

1. User holds an expense → sets transaction.comment.hold
2. User taps "Mark as done" → calls submitReport() → sets report.statusNum = CLOSED, report.stateNum = APPROVED
3. submitReport() never modifies transaction.comment.hold
4. useMoneyReportHeaderStatusBar calls hasOnlyHeldExpenses(transactions) → finds transaction.comment.hold still truthy
5. Returns statusBarType = ON_HOLD → banner renders

Key files:

• useMoneyReportHeaderStatusBar.ts:77,104-105 — hold banner visibility logic
• TransactionUtils/index.ts:1953-1959 — isOnHold() checks only transaction.comment.hold
• ReportWorkflow.ts:646-668 — approve flow clears holds (the pattern to replicate)
• ReportWorkflow.ts:1386-1404 — submit flow does NOT clear holds (the gap)

---

Next Steps for Contributor+ team: Reply with @MelvinBot implement this to create a draft PR, @MelvinBot <your feedback> to refine this analysis, or explain why you are rejecting Melvin's proposal.

[MobileMage]

Proposal

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

After a track-intent user puts a track-distance expense on hold and then taps More - Mark as done, the report status bar in the header still renders the "expense is on hold" message even though the report has just been submitted/closed. The expected behavior is that "Mark as done" releases the hold as part of submitting the report, so the header reflects the new state.

What is the root cause of that problem?

The hold signal is stored entirely on the transaction via transaction.comment.hold. When a user holds an expense, putOnHold in src/libs/actions/IOU/Hold.ts writes transaction.comment.hold = createdReportAction.reportActionID to Onyx (this is the only mutation that drives the on-hold state).

App/src/libs/actions/IOU/Hold.ts

Lines 97 to 106 in 8d99383

	{
	onyxMethod: Onyx.METHOD.MERGE,
	key: `${ONYXKEYS.COLLECTION.TRANSACTION}${transactionID}`,
	value: {
	pendingAction: CONST.RED_BRICK_ROAD_PENDING_ACTION.UPDATE,
	comment: {
	hold: createdReportAction.reportActionID,
	},
	},
	},

The header read path uses isOnHold from TransactionUtils, which is the strict check !!transaction.comment?.hold — there is no gate by report status, by track-intent, or by anything else. MoneyRequestHeader evaluates that boolean on every render and pushes the "expenseOnHold" status bar when it is truthy (src/components/MoneyRequestHeader.tsx#L85 and #L107-L109).

"Mark as done" is just the track-intent label for the regular submit action — SubmitPrimaryAction calls submitReport from src/libs/actions/IOU/ReportWorkflow.ts unchanged, only the button text differs via shouldShowMarkAsDone. The bug is that submitReport never touches comment.hold on any of the report's held transactions in its optimisticData/successData/failureData. Compare this with the sibling action approve in the same file, which explicitly clears holds when the user fully approves a report:

App/src/libs/actions/IOU/ReportWorkflow.ts

Lines 646 to 668 in 8d99383

	// Clear hold reason of all transactions if we approve all requests
	if (full && hasHeldExpenses) {
	const heldTransactions = getAllHeldTransactionsReportUtils(expenseReport.reportID);
	for (const heldTransaction of heldTransactions) {
	optimisticData.push({
	onyxMethod: Onyx.METHOD.MERGE,
	key: `${ONYXKEYS.COLLECTION.TRANSACTION}${heldTransaction.transactionID}`,
	value: {
	comment: {
	hold: '',
	},
	},
	});
	failureData.push({
	onyxMethod: Onyx.METHOD.MERGE,
	key: `${ONYXKEYS.COLLECTION.TRANSACTION}${heldTransaction.transactionID}`,
	value: {
	comment: {
	hold: heldTransaction.comment?.hold,
	},
	},
	});
	}

Because submitReport lacks an analogous block, the held transaction's comment.hold remains the original report action ID after the report transitions to SUBMITTED/CLOSED, isOnHold(transaction) stays true, and MoneyRequestHeader keeps rendering the hold status bar. This affects both the submit-and-close path (track-intent "Mark as done") and the normal submit path — the user has no way to unhold a transaction on a non-OPEN report, so the stale signal sticks around indefinitely.

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

Add a "Clear hold reason of all transactions if we submit the report" block in submitReport, mirroring the existing block in approve. Right after the failureData is built for the report (around the end of the failureData setup, just before parameters is assembled near line 1542 of src/libs/actions/IOU/ReportWorkflow.ts), call hasHeldExpensesReportUtils(getReportTransactions(expenseReport.reportID)) to detect held transactions, then iterate getAllHeldTransactionsReportUtils(expenseReport.reportID) and push for each held transaction (1) an optimisticData MERGE that sets comment.hold to '' on ${ONYXKEYS.COLLECTION.TRANSACTION}${heldTransaction.transactionID}, and (2) a failureData MERGE that restores comment.hold to heldTransaction.comment?.hold so a server-side failure rolls the hold back. Both helpers (getAllHeldTransactionsReportUtils, hasHeldExpensesReportUtils) are already imported at the top of the file, so no new imports are required.

This fix matches the existing approve precedent exactly, is symmetric with how the backend treats a submitted/closed report (a closed report cannot have an unhold action performed on it, so the hold metadata must be cleared as part of submission), and covers both the submit-and-close case ("Mark as done" for track-intent users, going straight to CLOSED) and the normal submit case (going to SUBMITTED). The LHN concern in the bug report (latest status should be "marked as done") is already handled by the existing lastMessageText/lastMessageHtml writes from optimisticSubmittedReportAction at line 1366-1367 — once the hold clears on the transaction, the LHN row stops being dominated by the hold preview as well.

What alternative solutions did you explore? (Optional)

We considered guarding the read side instead — adding isOpenExpenseReportReportUtils(parentReport) to the isOnHold branch in MoneyRequestHeader.getStatusBarProps. We rejected it because the stale comment.hold would still leak into every other consumer of isOnHold (the LHN hold badge, MoneyRequestReportPreview, useHoldRejectActions, secondary actions, search list items, etc.), so the fix needs to be at the write path. We also considered tying the cleanup to the backend HOLDREMOVED action coming back through Pusher, but the optimistic path is what the bug report observes, so the clear must be optimistic to match approve's behavior.

[melvin-bot]

Triggered auto assignment to Contributor-plus team member for initial proposal review - @eVoloshchak (External)

[melvin-bot]

Job added to Upwork: https://www.upwork.com/jobs/~022059476629104425841

[lxyct825-ops]

🚫 Duplicated proposal withdrawn by 🤖 ProposalPolice.

[aswin-s]

🚫 Duplicated proposal withdrawn by 🤖 ProposalPolice.