[$250] Expenses held by submitter are still auto-submitted

[m-natarajan]

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:
Reproducible in staging?: Needs Reproduction (Unable to reproduce)
Reproducible in production?: Needs Reproduction
If this was caught during regression testing, add the test name, ID and link from BrowserStack:
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Expensify/Expensify Issue URL:
Issue reported by: @garrettmknight
Slack conversation (hyperlinked to channel name): #Expensify Bugs

Action Performed:

1. Enable automatic Submission, set it to Daily
2. Create an expense report and add 3 expenses without violations to it
3. Put two of the expenses on hold
4. Wait till the harvester runs (or manually run it to test)

Expected Result:

Both held expenses should be moved to a new report in the Draft state. The remaining unheld expense should submit.

Actual Result:

All expenses were submitted, regardless of being held

Workaround:

Unknown

Platforms:

Select the officially supported platforms where the issue was reproduced:

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

Screenshots/Videos

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022056731705841376719
• Upwork Job ID: 2056731705841376719
• Last Price Increase: 2026-05-19

[MelvinBot]

Proposal

What is the root cause of that problem?

The submitReport() function and the canSubmitReport() gate have no hold-aware logic. When the backend harvester auto-submits a report, it calls SubmitReport which processes the entire report — held expenses included.

By contrast, the approval flow properly handles this: approveMoneyRequest checks hasHeldExpenses and calls getReportFromHoldRequestsOnyxData to split held expenses into a new draft report. The submit flow has no equivalent.

Specifically:

• canSubmitReport checks many conditions but never checks hold state.
• hasSubmissionBlockingViolations only blocks on SMARTSCAN_FAILED and NO_ROUTE — the HOLD violation is not treated as submission-blocking.
• submitReport sends the full report to the backend with no hold filtering or splitting.

The product intent is documented in en.ts:1583: "Held expenses are left behind even if you submit an entire report." — but this behavior is only enforced during approval, not submission.

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

Mirror the approval flow's hold-splitting logic in the submit flow:

1. In submitReport() (ReportWorkflow.ts), add a check for held expenses (using hasHeldExpenses from ReportUtils). If the report contains a mix of held and unheld expenses, call getReportFromHoldRequestsOnyxData (from Hold.ts) to create a new draft report for the held transactions — the same pattern used in approveMoneyRequest.

2. If all expenses on the report are held, the report should not be submitted at all. Update canSubmitReport() to return false when the report contains only held expenses (using hasOnlyHeldExpenses from ReportUtils).

3. The backend harvester should also be updated to respect hold state, but the client-side changes above will provide the correct optimistic behavior and ensure manual submission also handles holds properly.

What alternative solutions did you explore?

An alternative would be to only fix this on the backend harvester side, since auto-submit is a backend process. However, the same bug exists for manual submission from the client — if a user manually submits a report with held expenses, the client also doesn't split them. Fixing both client and backend ensures consistent behavior.

Supporting evidence

Hold mechanism: A transaction is held by setting transaction.comment.hold to a reportActionID (Hold.ts:98). The check is simply !!transaction.comment?.hold in isOnHold().

Approval flow (working correctly): approveMoneyRequest checks hasHeldExpenses and uses getReportFromHoldRequestsOnyxData to split held expenses into a new report and adjust totals.

Submit flow (missing logic): submitReport has zero hold-related checks in its ~275 lines.

SubmitReport API params only include reportID, managerAccountID, and reportActionID — no hold-related fields (SubmitReportParams.ts).

---

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.

[yusufdeveloper2903]

🚨 Edited by proposal-police: This proposal was edited at 2026-05-19 13:45:05 UTC.

Proposal

What is the root cause of that problem?

The auto-submit harvester is a server-side cron (OldDot / Web-Expensify) and out of App scope — but the same hold-split gap exists in the App's manual submit path, and the harvester invokes the same SubmitReport endpoint, so the App is half of the fix.

submitReport at

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

Lines 1237 to 1512 in d8a8d01

	function submitReport({
	expenseReport,
	policy,
	currentUserAccountIDParam,
	currentUserEmailParam,
	hasViolations,
	isASAPSubmitBetaEnabled,
	expenseReportCurrentNextStepDeprecated,
	userBillingGracePeriodEnds,
	amountOwed,
	onSubmitted,
	ownerBillingGracePeriodEnd,
	delegateEmail,
	}: SubmitReportFunctionParams) {
	if (!expenseReport) {
	return;
	}
	if (expenseReport.policyID && shouldRestrictUserBillableActions(policy, ownerBillingGracePeriodEnd, userBillingGracePeriodEnds, amountOwed, currentUserAccountIDParam)) {
	Navigation.navigate(ROUTES.RESTRICTED_ACTION.getRoute(expenseReport.policyID));
	return;
	}
	const isSubmitAndClosePolicy = isSubmitAndClose(policy);
	const adminAccountID = policy?.role === CONST.POLICY.ROLE.ADMIN ? currentUserAccountIDParam : undefined;
	const parentReport = getReportOrDraftReport(expenseReport.parentReportID);
	const managerID = getSubmitReportManagerAccountID(policy, expenseReport);
	const isCurrentUserManager = currentUserAccountIDParam === managerID;
	const optimisticSubmittedReportAction = buildOptimisticSubmittedReportAction(
	expenseReport?.total ?? 0,
	expenseReport.currency ?? '',
	expenseReport.reportID,
	adminAccountID,
	policy?.approvalMode,
	delegateEmail,
	);
	const isDEWPolicy = hasDynamicExternalWorkflow(policy);
	// For DEW policies, only add optimistic submit action when offline
	const shouldAddOptimisticSubmitAction = !isDEWPolicy || getIsOffline();
	// buildOptimisticNextStep is used in parallel
	const optimisticNextStepDeprecated = isDEWPolicy
	? null
	: buildNextStepNew({
	report: expenseReport,
	predictedNextStatus: isSubmitAndClosePolicy ? CONST.REPORT.STATUS_NUM.CLOSED : CONST.REPORT.STATUS_NUM.SUBMITTED,
	policy,
	currentUserAccountIDParam,
	currentUserEmailParam,
	hasViolations,
	isASAPSubmitBetaEnabled,
	isUnapprove: true,
	});
	const optimisticNextStep = isDEWPolicy
	? null
	: buildOptimisticNextStep({
	report: expenseReport,
	predictedNextStatus: isSubmitAndClosePolicy ? CONST.REPORT.STATUS_NUM.CLOSED : CONST.REPORT.STATUS_NUM.SUBMITTED,
	policy,
	currentUserAccountIDParam,
	currentUserEmailParam,
	hasViolations,
	isASAPSubmitBetaEnabled,
	isUnapprove: true,
	});
	const optimisticData: Array<
	OnyxUpdate<typeof ONYXKEYS.COLLECTION.REPORT_ACTIONS | typeof ONYXKEYS.COLLECTION.REPORT | typeof ONYXKEYS.COLLECTION.NEXT_STEP | typeof ONYXKEYS.COLLECTION.REPORT_METADATA>
	> = [];
	if (shouldAddOptimisticSubmitAction) {
	optimisticData.push({
	onyxMethod: Onyx.METHOD.MERGE,
	key: `${ONYXKEYS.COLLECTION.REPORT_ACTIONS}${expenseReport.reportID}`,
	value: {
	[optimisticSubmittedReportAction.reportActionID]: {
	...(optimisticSubmittedReportAction as OnyxTypes.ReportAction),
	pendingAction: CONST.RED_BRICK_ROAD_PENDING_ACTION.ADD,
	},
	},
	});
	}
	if (!isSubmitAndClosePolicy) {
	optimisticData.push({
	onyxMethod: Onyx.METHOD.MERGE,
	key: `${ONYXKEYS.COLLECTION.REPORT}${expenseReport.reportID}`,
	value: {
	...expenseReport,
	...(shouldAddOptimisticSubmitAction
	? {
	lastMessageText: getReportActionText(optimisticSubmittedReportAction),
	lastMessageHtml: getReportActionHtml(optimisticSubmittedReportAction),
	}
	: {}),
	// For DEW policies, don't optimistically update managerID, stateNum, statusNum, or nextStep
	// because DEW determines the actual workflow on the backend
	...(isDEWPolicy
	? {}
	: {
	managerID,
	stateNum: CONST.REPORT.STATE_NUM.SUBMITTED,
	statusNum: CONST.REPORT.STATUS_NUM.SUBMITTED,
	nextStep: optimisticNextStep,
	pendingFields: {
	nextStep: CONST.RED_BRICK_ROAD_PENDING_ACTION.UPDATE,
	},
	}),
	},
	});
	} else {
	optimisticData.push({
	onyxMethod: Onyx.METHOD.MERGE,
	key: `${ONYXKEYS.COLLECTION.REPORT}${expenseReport.reportID}`,
	value: {
	...expenseReport,
	// For DEW policies, don't optimistically update stateNum, statusNum, or nextStep
	...(isDEWPolicy
	? {}
	: {
	stateNum: CONST.REPORT.STATE_NUM.APPROVED,
	statusNum: CONST.REPORT.STATUS_NUM.CLOSED,
	nextStep: optimisticNextStep,
	pendingFields: {
	nextStep: CONST.RED_BRICK_ROAD_PENDING_ACTION.UPDATE,
	},
	}),
	},
	});
	}
	if (!isDEWPolicy) {
	optimisticData.push({
	onyxMethod: Onyx.METHOD.MERGE,
	key: `${ONYXKEYS.COLLECTION.NEXT_STEP}${expenseReport.reportID}`,
	value: optimisticNextStepDeprecated,
	});
	}
	if (parentReport?.reportID) {
	optimisticData.push({
	onyxMethod: Onyx.METHOD.MERGE,
	key: `${ONYXKEYS.COLLECTION.REPORT}${parentReport.reportID}`,
	value: {
	...parentReport,
	// In case its a manager who force submitted the report, they are the next user who needs to take an action
	hasOutstandingChildRequest: isCurrentUserManager,
	iouReportID: null,
	},
	});
	}
	if (isDEWPolicy) {
	optimisticData.push({
	onyxMethod: Onyx.METHOD.MERGE,
	key: `${ONYXKEYS.COLLECTION.REPORT_METADATA}${expenseReport.reportID}`,
	value: {
	pendingExpenseAction: CONST.EXPENSE_PENDING_ACTION.SUBMIT,
	},
	});
	}
	const successData: Array<OnyxUpdate<typeof ONYXKEYS.COLLECTION.REPORT | typeof ONYXKEYS.COLLECTION.REPORT_ACTIONS | typeof ONYXKEYS.COLLECTION.REPORT_METADATA>> = [];
	if (!isDEWPolicy) {
	successData.push({
	onyxMethod: Onyx.METHOD.MERGE,
	key: `${ONYXKEYS.COLLECTION.REPORT}${expenseReport.reportID}`,
	value: {
	pendingFields: {
	nextStep: null,
	},
	},
	});
	}
	if (shouldAddOptimisticSubmitAction) {
	successData.push({
	onyxMethod: Onyx.METHOD.MERGE,
	key: `${ONYXKEYS.COLLECTION.REPORT_ACTIONS}${expenseReport.reportID}`,
	value: {
	[optimisticSubmittedReportAction.reportActionID]: {
	pendingAction: null,
	},
	},
	});
	}
	if (isDEWPolicy) {
	successData.push({
	onyxMethod: Onyx.METHOD.MERGE,
	key: `${ONYXKEYS.COLLECTION.REPORT_METADATA}${expenseReport.reportID}`,
	value: {
	pendingExpenseAction: null,
	},
	});
	}
	const failureData: Array<
	OnyxUpdate<typeof ONYXKEYS.COLLECTION.REPORT | typeof ONYXKEYS.COLLECTION.NEXT_STEP | typeof ONYXKEYS.COLLECTION.REPORT_ACTIONS | typeof ONYXKEYS.COLLECTION.REPORT_METADATA>
	> = [
	{
	onyxMethod: Onyx.METHOD.MERGE,
	key: `${ONYXKEYS.COLLECTION.REPORT}${expenseReport.reportID}`,
	value: {
	statusNum: expenseReport.statusNum,
	stateNum: expenseReport.stateNum,
	managerID: expenseReport.managerID,
	...(isDEWPolicy
	? {}
	: {
	nextStep: expenseReport.nextStep ?? null,
	pendingFields: {
	nextStep: null,
	},
	}),
	},
	},
	];
	if (shouldAddOptimisticSubmitAction) {
	if (isDEWPolicy) {
	// delete the optimistic SUBMITTED action as The backend creates a DEW_SUBMIT_FAILED action instead.
	failureData.push({
	onyxMethod: Onyx.METHOD.MERGE,
	key: `${ONYXKEYS.COLLECTION.REPORT_ACTIONS}${expenseReport.reportID}`,
	value: {
	[optimisticSubmittedReportAction.reportActionID]: null,
	},
	});
	} else {
	failureData.push({
	onyxMethod: Onyx.METHOD.MERGE,
	key: `${ONYXKEYS.COLLECTION.REPORT_ACTIONS}${expenseReport.reportID}`,
	value: {
	[optimisticSubmittedReportAction.reportActionID]: {
	errors: getMicroSecondOnyxErrorWithTranslationKey('iou.error.other'),
	},
	},
	});
	}
	}
	if (isDEWPolicy) {
	failureData.push({
	onyxMethod: Onyx.METHOD.MERGE,
	key: `${ONYXKEYS.COLLECTION.REPORT_METADATA}${expenseReport.reportID}`,
	value: {
	pendingExpenseAction: null,
	},
	});
	}
	if (!isDEWPolicy) {
	failureData.push({
	onyxMethod: Onyx.METHOD.MERGE,
	key: `${ONYXKEYS.COLLECTION.NEXT_STEP}${expenseReport.reportID}`,
	value: expenseReportCurrentNextStepDeprecated ?? null,
	});
	}
	if (parentReport?.reportID) {
	failureData.push({
	onyxMethod: Onyx.METHOD.MERGE,
	key: `${ONYXKEYS.COLLECTION.REPORT}${parentReport.reportID}`,
	value: {
	hasOutstandingChildRequest: parentReport.hasOutstandingChildRequest,
	iouReportID: expenseReport.reportID,
	},
	});
	}
	const parameters: SubmitReportParams = {
	reportID: expenseReport.reportID,
	managerAccountID: managerID,
	reportActionID: optimisticSubmittedReportAction.reportActionID,
	};
	onSubmitted?.();
	API.write(WRITE_COMMANDS.SUBMIT_REPORT, parameters, {optimisticData, successData, failureData});
	}

builds optimistic data that snapshots the entire expenseReport with stateNum: SUBMITTED (L1318-L1344) and ships only {reportID, managerAccountID, reportActionID} to SUBMIT_REPORT (

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

Lines 1 to 7 in d8a8d01

	type SubmitReportParams = {
	reportID: string;
	managerAccountID?: number;
	reportActionID: string;
	};
	export default SubmitReportParams;

). There is no hasHeldExpenses branch, no unheldTotal substitution, no call to getReportFromHoldRequestsOnyxData.

Compare to approveMoneyRequest at

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

Lines 341 to 706 in d8a8d01

	function approveMoneyRequest(params: ApproveMoneyRequestFunctionParams) {
	const {
	expenseReport,
	policy,
	currentUserAccountIDParam,
	currentUserEmailParam,
	hasViolations,
	isASAPSubmitBetaEnabled,
	expenseReportCurrentNextStepDeprecated,
	betas,
	userBillingGracePeriodEnds,
	amountOwed,
	full,
	onApproved,
	ownerBillingGracePeriodEnd,
	delegateEmail,
	expenseReportPolicy,
	} = params;
	if (!expenseReport) {
	return;
	}
	if (expenseReport.policyID && shouldRestrictUserBillableActions(expenseReportPolicy, ownerBillingGracePeriodEnd, userBillingGracePeriodEnds, amountOwed, currentUserAccountIDParam)) {
	Navigation.navigate(ROUTES.RESTRICTED_ACTION.getRoute(expenseReport.policyID));
	return;
	}
	let total = expenseReport.total ?? 0;
	const hasHeldExpenses = hasHeldExpensesReportUtils(expenseReport.reportID);
	const hasDuplicates = hasDuplicateTransactions(currentUserEmailParam, currentUserAccountIDParam, expenseReport, policy, getAllTransactionViolations());
	if (hasHeldExpenses && !full && !!expenseReport.unheldTotal) {
	total = expenseReport.unheldTotal;
	}
	const optimisticApprovedReportAction = buildOptimisticApprovedReportAction(total, expenseReport.currency ?? '', expenseReport.reportID, currentUserAccountIDParam, delegateEmail);
	const isDEWPolicy = hasDynamicExternalWorkflow(policy);
	const shouldAddOptimisticApproveAction = !isDEWPolicy || getIsOffline();
	const nextApproverAccountID = getNextApproverAccountID(expenseReport);
	const predictedNextStatus = !nextApproverAccountID ? CONST.REPORT.STATUS_NUM.APPROVED : CONST.REPORT.STATUS_NUM.SUBMITTED;
	const predictedNextState = !nextApproverAccountID ? CONST.REPORT.STATE_NUM.APPROVED : CONST.REPORT.STATE_NUM.SUBMITTED;
	const managerID = !nextApproverAccountID ? expenseReport.managerID : nextApproverAccountID;
	// buildOptimisticNextStep is used in parallel
	const optimisticNextStepDeprecated = isDEWPolicy
	? null
	: buildNextStepNew({
	report: expenseReport,
	policy,
	currentUserAccountIDParam,
	currentUserEmailParam,
	hasViolations,
	isASAPSubmitBetaEnabled,
	predictedNextStatus,
	});
	const optimisticNextStep = isDEWPolicy
	? null
	: buildOptimisticNextStep({
	report: expenseReport,
	policy,
	currentUserAccountIDParam,
	currentUserEmailParam,
	hasViolations,
	isASAPSubmitBetaEnabled,
	predictedNextStatus,
	});
	const chatReport = getReportOrDraftReport(expenseReport.chatReportID);
	const optimisticData: Array<
	OnyxUpdate<
	| typeof ONYXKEYS.COLLECTION.REPORT
	| typeof ONYXKEYS.COLLECTION.REPORT_ACTIONS
	| typeof ONYXKEYS.COLLECTION.TRANSACTION
	| typeof ONYXKEYS.COLLECTION.NEXT_STEP
	| typeof ONYXKEYS.COLLECTION.REPORT_METADATA
	| typeof ONYXKEYS.COLLECTION.TRANSACTION_VIOLATIONS
	>
	> = [];
	if (shouldAddOptimisticApproveAction) {
	optimisticData.push({
	onyxMethod: Onyx.METHOD.MERGE,
	key: `${ONYXKEYS.COLLECTION.REPORT_ACTIONS}${expenseReport.reportID}`,
	value: {
	[optimisticApprovedReportAction.reportActionID]: {
	...(optimisticApprovedReportAction as OnyxTypes.ReportAction),
	pendingAction: CONST.RED_BRICK_ROAD_PENDING_ACTION.ADD,
	},
	},
	});
	}
	const updatedExpenseReport = {
	...expenseReport,
	...(shouldAddOptimisticApproveAction
	? {
	lastMessageText: getReportActionText(optimisticApprovedReportAction),
	lastMessageHtml: getReportActionHtml(optimisticApprovedReportAction),
	}
	: {}),
	// For DEW policies, don't optimistically update stateNum, statusNum, managerID, or nextStep
	// because DEW determines the actual workflow on the backend
	...(isDEWPolicy
	? {}
	: {
	stateNum: predictedNextState,
	statusNum: predictedNextStatus,
	managerID,
	nextStep: optimisticNextStep ?? undefined,
	pendingFields: {
	partial: full ? null : CONST.RED_BRICK_ROAD_PENDING_ACTION.UPDATE,
	nextStep: CONST.RED_BRICK_ROAD_PENDING_ACTION.UPDATE,
	},
	}),
	};
	optimisticData.push({
	onyxMethod: Onyx.METHOD.MERGE,
	key: `${ONYXKEYS.COLLECTION.REPORT}${expenseReport.reportID}`,
	value: updatedExpenseReport,
	});
	if (chatReport) {
	optimisticData.push({
	onyxMethod: Onyx.METHOD.MERGE,
	key: `${ONYXKEYS.COLLECTION.REPORT}${expenseReport.chatReportID}`,
	value: {
	hasOutstandingChildRequest: hasOutstandingChildRequest(
	chatReport,
	updatedExpenseReport,
	currentUserEmailParam,
	currentUserAccountIDParam,
	getAllTransactionViolations(),
	undefined,
	),
	},
	});
	}
	if (!isDEWPolicy) {
	optimisticData.push({
	onyxMethod: Onyx.METHOD.MERGE,
	key: `${ONYXKEYS.COLLECTION.NEXT_STEP}${expenseReport.reportID}`,
	value: optimisticNextStepDeprecated,
	});
	}
	if (isDEWPolicy) {
	optimisticData.push({
	onyxMethod: Onyx.METHOD.MERGE,
	key: `${ONYXKEYS.COLLECTION.REPORT_METADATA}${expenseReport.reportID}`,
	value: {
	pendingExpenseAction: CONST.EXPENSE_PENDING_ACTION.APPROVE,
	},
	});
	}
	const successData: Array<OnyxUpdate<typeof ONYXKEYS.COLLECTION.REPORT | typeof ONYXKEYS.COLLECTION.REPORT_ACTIONS | typeof ONYXKEYS.COLLECTION.REPORT_METADATA>> = [];
	if (!isDEWPolicy) {
	successData.push({
	onyxMethod: Onyx.METHOD.MERGE,
	key: `${ONYXKEYS.COLLECTION.REPORT}${expenseReport.reportID}`,
	value: {
	pendingFields: {
	partial: null,
	nextStep: null,
	},
	},
	});
	}
	if (shouldAddOptimisticApproveAction) {
	successData.push({
	onyxMethod: Onyx.METHOD.MERGE,
	key: `${ONYXKEYS.COLLECTION.REPORT_ACTIONS}${expenseReport.reportID}`,
	value: {
	[optimisticApprovedReportAction.reportActionID]: {
	pendingAction: null,
	},
	},
	});
	}
	if (isDEWPolicy) {
	successData.push({
	onyxMethod: Onyx.METHOD.MERGE,
	key: `${ONYXKEYS.COLLECTION.REPORT_METADATA}${expenseReport.reportID}`,
	value: {
	pendingExpenseAction: null,
	},
	});
	}
	const failureData: Array<
	OnyxUpdate<
	| typeof ONYXKEYS.COLLECTION.REPORT
	| typeof ONYXKEYS.COLLECTION.REPORT_ACTIONS
	| typeof ONYXKEYS.COLLECTION.NEXT_STEP
	| typeof ONYXKEYS.COLLECTION.REPORT_METADATA
	| typeof ONYXKEYS.COLLECTION.TRANSACTION
	| typeof ONYXKEYS.COLLECTION.TRANSACTION_VIOLATIONS
	>
	> = [
	{
	onyxMethod: Onyx.METHOD.MERGE,
	key: `${ONYXKEYS.COLLECTION.REPORT}${expenseReport.chatReportID}`,
	value: {
	hasOutstandingChildRequest: chatReport?.hasOutstandingChildRequest,
	},
	},
	{
	onyxMethod: Onyx.METHOD.MERGE,
	key: `${ONYXKEYS.COLLECTION.NEXT_STEP}${expenseReport.reportID}`,
	value: expenseReportCurrentNextStepDeprecated ?? null,
	},
	];
	if (!isDEWPolicy) {
	failureData.push({
	onyxMethod: Onyx.METHOD.MERGE,
	key: `${ONYXKEYS.COLLECTION.REPORT}${expenseReport.reportID}`,
	value: {
	statusNum: expenseReport.statusNum,
	stateNum: expenseReport.stateNum,
	nextStep: expenseReport.nextStep ?? null,
	pendingFields: {
	partial: null,
	nextStep: null,
	},
	},
	});
	}
	if (shouldAddOptimisticApproveAction) {
	if (isDEWPolicy) {
	failureData.push({
	onyxMethod: Onyx.METHOD.MERGE,
	key: `${ONYXKEYS.COLLECTION.REPORT_ACTIONS}${expenseReport.reportID}`,
	value: {
	[optimisticApprovedReportAction.reportActionID]: null,
	},
	});
	} else {
	failureData.push({
	onyxMethod: Onyx.METHOD.MERGE,
	key: `${ONYXKEYS.COLLECTION.REPORT_ACTIONS}${expenseReport.reportID}`,
	value: {
	[optimisticApprovedReportAction.reportActionID]: {
	errors: getMicroSecondOnyxErrorWithTranslationKey('iou.error.other'),
	},
	},
	});
	}
	}
	if (isDEWPolicy) {
	failureData.push({
	onyxMethod: Onyx.METHOD.MERGE,
	key: `${ONYXKEYS.COLLECTION.REPORT_METADATA}${expenseReport.reportID}`,
	value: {
	pendingExpenseAction: null,
	},
	});
	}
	// 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,
	},
	},
	});
	}
	}
	let optimisticHoldReportID;
	let optimisticHoldActionID;
	let optimisticHoldReportExpenseActionIDs;
	let optimisticReportActionCopyIDs;
	let optimisticCreatedReportForUnapprovedTransactionsActionID;
	if (!full && !!chatReport && !!expenseReport) {
	const originalCreated = getReportOriginalCreationTimestamp(expenseReport);
	const holdReportOnyxData = getReportFromHoldRequestsOnyxData({
	chatReport,
	iouReport: expenseReport,
	recipient: {accountID: expenseReport.ownerAccountID},
	policy,
	createdTimestamp: originalCreated,
	isApprovalFlow: true,
	betas,
	});
	optimisticData.push(...holdReportOnyxData.optimisticData);
	successData.push(...holdReportOnyxData.successData);
	failureData.push(...holdReportOnyxData.failureData);
	optimisticHoldReportID = holdReportOnyxData.optimisticHoldReportID;
	optimisticHoldActionID = holdReportOnyxData.optimisticHoldActionID;
	optimisticCreatedReportForUnapprovedTransactionsActionID = holdReportOnyxData.optimisticCreatedReportForUnapprovedTransactionsActionID;
	optimisticHoldReportExpenseActionIDs = JSON.stringify(holdReportOnyxData.optimisticHoldReportExpenseActionIDs);
	optimisticReportActionCopyIDs = JSON.stringify(holdReportOnyxData.optimisticReportActionCopyIDs);
	}
	// Remove duplicates violations if we approve the report
	if (hasDuplicates) {
	let transactions = getReportTransactions(expenseReport.reportID).filter((transaction) =>
	isDuplicate(
	transaction,
	currentUserEmailParam,
	currentUserAccountIDParam,
	expenseReport,
	policy,
	getAllTransactionViolations()?.[ONYXKEYS.COLLECTION.TRANSACTION_VIOLATIONS + transaction.transactionID],
	),
	);
	if (!full) {
	transactions = transactions.filter((transaction) => !isOnHold(transaction));
	}
	for (const transaction of transactions) {
	const transactionViolations = getAllTransactionViolations()?.[`${ONYXKEYS.COLLECTION.TRANSACTION_VIOLATIONS}${transaction.transactionID}`] ?? [];
	const newTransactionViolations = transactionViolations.filter((violation) => violation.name !== CONST.VIOLATIONS.DUPLICATED_TRANSACTION);
	optimisticData.push({
	onyxMethod: Onyx.METHOD.MERGE,
	key: `${ONYXKEYS.COLLECTION.TRANSACTION_VIOLATIONS}${transaction.transactionID}`,
	value: newTransactionViolations,
	});
	failureData.push({
	onyxMethod: Onyx.METHOD.MERGE,
	key: `${ONYXKEYS.COLLECTION.TRANSACTION_VIOLATIONS}${transaction.transactionID}`,
	value: transactionViolations,
	});
	}
	}
	const parameters: ApproveMoneyRequestParams = {
	reportID: expenseReport.reportID,
	approvedReportActionID: optimisticApprovedReportAction.reportActionID,
	full,
	optimisticHoldReportID,
	optimisticHoldActionID,
	optimisticHoldReportExpenseActionIDs,
	optimisticReportActionCopyIDs,
	optimisticCreatedReportForUnapprovedTransactionsActionID,
	};
	onApproved?.();
	playSound(SOUNDS.SUCCESS);
	API.write(WRITE_COMMANDS.APPROVE_MONEY_REQUEST, parameters, {optimisticData, successData, failureData});
	return optimisticHoldReportID;
	}

:

• L369-L373 detects held expenses and substitutes total = unheldTotal for the partial-approve total.
• L631-L656 calls getReportFromHoldRequestsOnyxData({iouReport, recipient, policy, betas, createdTimestamp, isApprovalFlow: true}) (definition at

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

  Lines 680 to 708 in d8a8d01

  	function getReportFromHoldRequestsOnyxData({
  	chatReport,
  	iouReport,
  	recipient,
  	policy,
  	createdTimestamp,
  	betas,
  	isApprovalFlow = false,
  	conciergeReportID,
  	}: {
  	chatReport: OnyxTypes.Report;
  	iouReport: OnyxEntry<OnyxTypes.Report>;
  	recipient: Participant;
  	policy: OnyxEntry<OnyxTypes.Policy>;
  	createdTimestamp?: string;
  	betas: OnyxEntry<OnyxTypes.Beta[]>;
  	isApprovalFlow?: boolean;
  	// TODO: This will be required eventually. Ref: https://github.com/Expensify/App/issues/66411
  	conciergeReportID?: string;
  	}): {
  	optimisticHoldReportID: string;
  	optimisticHoldActionID: string;
  	optimisticCreatedReportForUnapprovedTransactionsActionID: string | undefined;
  	optimisticHoldReportExpenseActionIDs: OptimisticHoldReportExpenseActionID[];
  	optimisticReportActionCopyIDs: OptimisticReportActionCopyIDs;
  	optimisticData: Array<OnyxUpdate<typeof ONYXKEYS.COLLECTION.REPORT | typeof ONYXKEYS.COLLECTION.REPORT_ACTIONS | typeof ONYXKEYS.COLLECTION.TRANSACTION>>;
  	successData: Array<OnyxUpdate<typeof ONYXKEYS.COLLECTION.REPORT_ACTIONS>>;
  	failureData: Array<OnyxUpdate<typeof ONYXKEYS.COLLECTION.REPORT | typeof ONYXKEYS.COLLECTION.REPORT_ACTIONS | typeof ONYXKEYS.COLLECTION.TRANSACTION>>;
  	} {

  ) to build a new optimistic draft report for the held transactions plus copied parent report actions, and threads optimisticHoldReportID / optimisticHoldActionID / optimisticHoldReportExpenseActionIDs / optimisticReportActionCopyIDs / optimisticCreatedReportForUnapprovedTransactionsActionID through ApproveMoneyRequestParams (

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

  Lines 1 to 26 in d8a8d01

  	type ApproveMoneyRequestParams = {
  	reportID: string;
  	approvedReportActionID: string;
  	full?: boolean;
  	optimisticHoldReportID?: string;
  	optimisticHoldActionID?: string;
  	/**
  	* Stringified JSON object with type of following structure:
  	* Array<{
  	* optimisticReportActionID: string;
  	* oldReportActionID: string;
  	* }>
  	*/
  	optimisticHoldReportExpenseActionIDs?: string;
  	/**
  	* Stringified JSON object of type Record<string, string> with the following structure:
  	* {
  	* [oldReportActionID]: optimisticReportActionID,
  	* }
  	* where optimisticReportActionID is the optimistic report action ID and oldReportActionID is the old report action ID
  	*/
  	optimisticReportActionCopyIDs?: string;
  	/** The optimistic action ID for the report created for unapproved transactions */
  	optimisticCreatedReportForUnapprovedTransactionsActionID?: string;
  	};

  ) so the backend honors the split.

Result: when a user manually clicks Submit on a Daily report with 2 held + 1 unheld expense, the App optimistically marks all three SUBMITTED and the server has no optimistic IDs to honor — same outcome the harvester produces, since the harvester batch-runs the same SubmitReport server handler.

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

Bring submitReport to parity with approveMoneyRequest's hold handling. Inside submitReport (before building optimisticSubmittedReportAction at L1264), detect held expenses, use unheldTotal for the submit, and call getReportFromHoldRequestsOnyxData({...isApprovalFlow: false}) to build the optimistic split:

+    const hasHeldExpenses = hasHeldExpensesReportUtils(expenseReport.reportID);
+    const submittingTotal = hasHeldExpenses && !!expenseReport.unheldTotal ? expenseReport.unheldTotal : expenseReport?.total ?? 0;
     const optimisticSubmittedReportAction = buildOptimisticSubmittedReportAction(
-        expenseReport?.total ?? 0,
+        submittingTotal,
         expenseReport.currency ?? '',
         expenseReport.reportID,
         adminAccountID,
         policy?.approvalMode,
         delegateEmail,
     );

Then mirror the L631-L656 block from approveMoneyRequest and forward the IDs into SUBMIT_REPORT:

+    let optimisticHoldReportID;
+    let optimisticHoldActionID;
+    let optimisticHoldReportExpenseActionIDs;
+    let optimisticReportActionCopyIDs;
+    if (hasHeldExpenses && !!chatReport) {
+        const holdReportOnyxData = getReportFromHoldRequestsOnyxData({
+            chatReport,
+            iouReport: expenseReport,
+            recipient: {accountID: expenseReport.ownerAccountID},
+            policy,
+            createdTimestamp: getReportOriginalCreationTimestamp(expenseReport),
+            isApprovalFlow: false,
+            betas,
+        });
+        optimisticData.push(...holdReportOnyxData.optimisticData);
+        successData.push(...holdReportOnyxData.successData);
+        failureData.push(...holdReportOnyxData.failureData);
+        optimisticHoldReportID = holdReportOnyxData.optimisticHoldReportID;
+        optimisticHoldActionID = holdReportOnyxData.optimisticHoldActionID;
+        optimisticHoldReportExpenseActionIDs = JSON.stringify(holdReportOnyxData.optimisticHoldReportExpenseActionIDs);
+        optimisticReportActionCopyIDs = JSON.stringify(holdReportOnyxData.optimisticReportActionCopyIDs);
+    }
     const parameters: SubmitReportParams = {
         reportID: expenseReport.reportID,
         managerAccountID: managerID,
         reportActionID: optimisticSubmittedReportAction.reportActionID,
+        optimisticHoldReportID,
+        optimisticHoldActionID,
+        optimisticHoldReportExpenseActionIDs,
+        optimisticReportActionCopyIDs,
     };

Supporting changes (described, no diff): extend SubmitReportParams (

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

Lines 1 to 7 in d8a8d01

	type SubmitReportParams = {
	reportID: string;
	managerAccountID?: number;
	reportActionID: string;
	};
	export default SubmitReportParams;

) with the four optional optimisticHold… string fields, matching the shape of ApproveMoneyRequestParams. Add betas: OnyxEntry<OnyxTypes.Beta[]> to SubmitReportFunctionParams (L94-L107) and pass it through from the caller (parallel to how approveMoneyRequest accepts betas at L85). Pass chatReport into submitReport the same way the approve callsite passes chatReport — currently submitReport doesn't take it; add it to the function params and resolve via getReportOrDraftReport(expenseReport.chatReportID) at the callsite or inside the function.

The harvester half (server-side SubmitReport handler / Daily harvest batch) is OldDot/Web-Expensify and out of App scope — that path needs the equivalent server-side split using the same optimisticHold… semantics. This App change closes the manual-submit half and gives the backend the optimistic IDs to honor on both code paths.

What alternative solutions did you explore? (Optional)

Hiding the Submit primary action when held expenses exist (e.g., extending isSubmitAction at

App/src/libs/ReportPrimaryActionUtils.ts

Lines 120 to 151 in d8a8d01

	const isOpenReport = isOpenReportUtils(report);
	if (hasPendingDEWSubmit(reportMetadata, hasDynamicExternalWorkflow(policy))) {
	return false;
	}
	if (!isPaidGroupPolicy(policy)) {
	return false;
	}
	if (reportTransactions.length > 0 && reportTransactions.every((transaction) => isPending(transaction) || isScanning(transaction))) {
	return false;
	}
	if (hasSmartScanFailedWithMissingFields(reportTransactions ?? [], report)) {
	return false;
	}
	if (violations && currentUserEmail && currentUserAccountID !== undefined) {
	if (reportTransactions.some((transaction) => hasSubmissionBlockingViolations(transaction, violations, currentUserEmail, currentUserAccountID, report, policy))) {
	return false;
	}
	}
	const submitToAccountID = getSubmitToAccountID(policy, report);
	if (submitToAccountID === report.ownerAccountID && policy?.preventSelfApproval && !isReportSubmitter) {
	return false;
	}
	return isExpenseReport && isReportSubmitter && isOpenReport && reportTransactions.length !== 0;
	}

to gate on hasOnlyHeldExpenses or any isOnHold transaction) — rejected because the bug requires the mixed held + unheld scenario (2 held, 1 unheld is the repro), and gating Submit would block legitimate partial-submit flows and would not affect the harvester. A reactive client-side undo (subscribe to the just-submitted report and post-hoc re-split if it still contains held items) — rejected: dependent on Onyx update ordering, leaves a visible "submitted then reverted" flash in the LHN, and forgoes modeling the split as a first-class optimistic action the way approve already does.

[melvin-bot]

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

[melvin-bot]

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

[github-actions]

⚠️ @yusufdeveloper2903 Thanks for your proposal. Please update it to follow the proposal template, as proposals are only reviewed if they follow that format (note the mandatory sections).

[mukhrr]

Proposal

What is the root cause of that problem?

Automatic submission is performed by the harvester, a server‑side cron job (Web‑Expensify / Auth), not by the App. When the harvester fires on the configured frequency (Daily here), it should submit only the expenses eligible for submission and spin off everything held by the submitter into a brand‑new draft report — the report the App already knows how to render:

App/src/languages/en.ts

Lines 898 to 899 in e3b5200

	harvestCreatedExpenseReport: (reportUrl: string, reportName: string) =>
	`created this report to hold all expenses from <a href="${reportUrl}">${reportName}</a> that couldn't be submitted on your chosen frequency`,

The App treats harvest reports as read‑only / backend‑driven — it only detects and displays them, it never builds the split itself:

App/src/libs/ReportUtils.ts

Lines 2357 to 2367 in e3b5200

	* Whether the report was created during harvesting
	*/
	function isHarvestCreatedExpenseReport(origin?: string, originalID?: string): boolean {
	return !!originalID && origin === 'harvest';
	}
	/**
	* Returns the original reportID for a harvest-created report
	*/
	function getHarvestOriginalReportID(origin?: string, originalID?: string): string | undefined {
	if (!originalID || !isHarvestCreatedExpenseReport(origin, originalID)) {

App/src/components/ReportActionItem/CreateHarvestReportAction.tsx

Lines 15 to 25 in e3b5200

	function CreateHarvestReportAction({reportNameValuePairsOriginalID}: CreateHarvestReportActionProps) {
	const {translate} = useLocalize();
	const [harvestReport] = useOnyx(`${ONYXKEYS.COLLECTION.REPORT}${reportNameValuePairsOriginalID}`);
	const harvestReportName = getReportName(harvestReport);
	const htmlContent = `<comment><muted-text>${getHarvestCreatedExpenseReportMessage(harvestReport?.reportID, harvestReportName, translate)}</muted-text></comment>`;
	return (
	<ReportActionItemBasicMessage>
	<RenderHTML html={htmlContent} />
	</ReportActionItemBasicMessage>
	);

So the bug is: the harvester's report‑building logic is not excluding submitter‑held transactions before auto‑submitting, and is therefore not creating the draft "harvest" report for them. Every expense — held or not — ends up on the submitted report.

For comparison, the App does implement this exact "leave held expenses behind in a new report" split for the manual approve and pay flows via getReportFromHoldRequestsOnyxData:

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

Lines 680 to 707 in e3b5200

	function getReportFromHoldRequestsOnyxData({
	chatReport,
	iouReport,
	recipient,
	policy,
	createdTimestamp,
	betas,
	isApprovalFlow = false,
	conciergeReportID,
	}: {
	chatReport: OnyxTypes.Report;
	iouReport: OnyxEntry<OnyxTypes.Report>;
	recipient: Participant;
	policy: OnyxEntry<OnyxTypes.Policy>;
	createdTimestamp?: string;
	betas: OnyxEntry<OnyxTypes.Beta[]>;
	isApprovalFlow?: boolean;
	// TODO: This will be required eventually. Ref: https://github.com/Expensify/App/issues/66411
	conciergeReportID?: string;
	}): {
	optimisticHoldReportID: string;
	optimisticHoldActionID: string;
	optimisticCreatedReportForUnapprovedTransactionsActionID: string | undefined;
	optimisticHoldReportExpenseActionIDs: OptimisticHoldReportExpenseActionID[];
	optimisticReportActionCopyIDs: OptimisticReportActionCopyIDs;
	optimisticData: Array<OnyxUpdate<typeof ONYXKEYS.COLLECTION.REPORT | typeof ONYXKEYS.COLLECTION.REPORT_ACTIONS | typeof ONYXKEYS.COLLECTION.TRANSACTION>>;
	successData: Array<OnyxUpdate<typeof ONYXKEYS.COLLECTION.REPORT_ACTIONS>>;
	failureData: Array<OnyxUpdate<typeof ONYXKEYS.COLLECTION.REPORT | typeof ONYXKEYS.COLLECTION.REPORT_ACTIONS | typeof ONYXKEYS.COLLECTION.TRANSACTION>>;

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

Lines 635 to 656 in e3b5200

	let optimisticCreatedReportForUnapprovedTransactionsActionID;
	if (!full && !!chatReport && !!expenseReport) {
	const originalCreated = getReportOriginalCreationTimestamp(expenseReport);
	const holdReportOnyxData = getReportFromHoldRequestsOnyxData({
	chatReport,
	iouReport: expenseReport,
	recipient: {accountID: expenseReport.ownerAccountID},
	policy,
	createdTimestamp: originalCreated,
	isApprovalFlow: true,
	betas,
	});
	optimisticData.push(...holdReportOnyxData.optimisticData);
	successData.push(...holdReportOnyxData.successData);
	failureData.push(...holdReportOnyxData.failureData);
	optimisticHoldReportID = holdReportOnyxData.optimisticHoldReportID;
	optimisticHoldActionID = holdReportOnyxData.optimisticHoldActionID;
	optimisticCreatedReportForUnapprovedTransactionsActionID = holdReportOnyxData.optimisticCreatedReportForUnapprovedTransactionsActionID;
	optimisticHoldReportExpenseActionIDs = JSON.stringify(holdReportOnyxData.optimisticHoldReportExpenseActionIDs);
	optimisticReportActionCopyIDs = JSON.stringify(holdReportOnyxData.optimisticReportActionCopyIDs);
	}

But submitReport deliberately has no such split (manual submit is allowed to carry held expenses), and — more importantly — the harvester never calls App code at all:

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

Lines 1237 to 1260 in e3b5200

	function submitReport({
	expenseReport,
	policy,
	currentUserAccountIDParam,
	currentUserEmailParam,
	hasViolations,
	isASAPSubmitBetaEnabled,
	expenseReportCurrentNextStepDeprecated,
	userBillingGracePeriodEnds,
	amountOwed,
	onSubmitted,
	ownerBillingGracePeriodEnd,
	delegateEmail,
	}: SubmitReportFunctionParams) {
	if (!expenseReport) {
	return;
	}
	if (expenseReport.policyID && shouldRestrictUserBillableActions(policy, ownerBillingGracePeriodEnd, userBillingGracePeriodEnds, amountOwed, currentUserAccountIDParam)) {
	Navigation.navigate(ROUTES.RESTRICTED_ACTION.getRoute(expenseReport.policyID));
	return;
	}
	const isSubmitAndClosePolicy = isSubmitAndClose(policy);
	const adminAccountID = policy?.role === CONST.POLICY.ROLE.ADMIN ? currentUserAccountIDParam : undefined;

This is why it is "Unable to reproduce" from the client and only surfaces after the Daily cron runs — it is a backend harvester defect, not a client one.

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

The fix belongs in the backend harvester (internal Web-Expensify/Auth scheduled‑submission job — not this App repo). When the harvester builds the report to auto‑submit, it must partition transactions by hold status, submit only the unheld ones, and create a new draft report for the held ones — the same contract the App's getReportFromHoldRequestsOnyxData encodes for approve/pay.

Conceptually (backend, pseudo‑diff):

- // Harvester: submit the whole open report on the chosen frequency
- submitReport(report, report.transactions);
+ // Harvester: only auto-submit expenses that are NOT held by the submitter
+ const heldTransactions   = report.transactions.filter(t => isHeldBySubmitter(t));
+ const unheldTransactions = report.transactions.filter(t => !isHeldBySubmitter(t));
+
+ if (heldTransactions.length > 0) {
+     // Move held expenses to a fresh DRAFT report (origin = 'harvest', originalID = report.reportID)
+     createHarvestDraftReport(report, heldTransactions);
+ }
+
+ if (unheldTransactions.length > 0) {
+     submitReport(report, unheldTransactions);
+ }

The held‑expense draft report it creates is already fully supported by the App — isHarvestCreatedExpenseReport (origin === 'harvest', originalID set) plus the harvestCreatedExpenseReport system message render it correctly with no App change required. No App‑side change is needed (and submitReport should not be modified, since manual submit intentionally keeps held expenses on the report).

What alternative solutions did you explore? (Optional)

• Add the hold‑split to the App's submitReport (mirror the approve flow's getReportFromHoldRequestsOnyxData call): rejected — submitReport is the manual submit path, where carrying held expenses is correct/intended; and the harvester never invokes it, so this would not fix the auto‑submit scenario while regressing manual submit.
• Filter held expenses optimistically on the client when a harvest report arrives: rejected — the App must not re‑derive backend‑owned report composition; the harvester is the single source of truth for what gets auto‑submitted.

[github-actions]

⚠️ @mukhrr Your proposal is a duplicate of an already existing proposal and has been automatically withdrawn to prevent spam. Please review the existing proposals before submitting a new one.

[KJ21-ENG]

Proposal

What is the root cause of that problem?

The daily auto-submit harvester is not partitioning held transactions out before it submits the report.

This has to happen on the backend because scheduled submit/report harvest runs there, not from NewDot. NewDot already models the desired split for partial hold flows: held transactions are detected from transaction.comment.hold, moved to a new expense report, and the original report totals are reduced to the unheld amount. The SubmitReport client command, by contrast, only sends the report id/manager/action id and cannot tell the harvester which transactions to split. So when the server-side harvest code submits the report as one unit, submitter-held expenses are included with the unheld expenses.

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

Update the backend report harvest path to treat held expenses as unsubmittable before submitting a report:

1. When harvesting an open expense report, load the report transactions and identify transactions whose hold state is set (comment.hold/the equivalent server-side hold marker).
2. Partition the report into held and unheld transaction ids.
3. If both groups exist, move the held transactions to a newly created harvest/draft expense report, preserving their hold state, hold report actions/thread parents, report action links, totals, and report NVPs used by NewDot to show the harvest-created report message.
4. Submit only the original report with the remaining unheld transactions.
5. If every transaction is held, do not submit them; leave/create the held draft report instead of producing an empty submitted report.

This should reuse the same backend primitive used for moving unsubmittable transactions during harvest, extending its eligibility filter to include held expenses, not just violation-based unsubmittable expenses.

Add backend coverage for:

• daily auto-submit with mixed held and unheld expenses: only unheld expenses submit, held expenses move to a draft harvest-created report;
• all expenses held: nothing held is submitted;
• hold created by the submitter specifically, since that is the reported failing case.

What alternative solutions did you explore? (Optional)

I considered fixing this in NewDot's SubmitReport flow, but that would not affect the daily harvester because it runs server-side. App-side changes would only affect manual user actions and would still allow the scheduled backend job to submit held expenses.