[$250] Expense - Waiting for you approve expenses display after employee submit the reject offline

[jponikarchuk]

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.73-2
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/test-runs/TR-28527/folder/27754595/78017654/1410973456
Email or phone of affected tester (no customers): lekima20+68905@gmail.com
Issue reported by: Applause Internal Team
Bug source: Regression TC Execution
Device used: Win 11/Chrome
App Component: Money Requests

Action Performed:

Precondition:

• User A create a workspace setting Submissions: Daily, enable Approval and Payment. Invite an employee to workspace
• Employee create and submit an expense to the workspace chat
• Admin reject the employee's expense

1. Open https://staging.new.expensify.com login as Employee
2. Employee navigate to the workspace chat
3. Turn off internet
4. Click on the rejected report to go expense detail page
5. Click on Submit button

Expected Result:

The message should update to "Waiting for user A to approve expenses"

Actual Result:

The message updates to "Waiting for you to approve expenses"

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Video.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

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

Issue Owner

Current Issue Owner: @yuwenmemon

[MelvinBot]

Proposal

What is the root cause of that problem?

When an admin rejects a report back to the submitter, RejectMoneyRequest.ts:1013 sets report.managerID to the employee's own accountID (the targetAccountID/ownerAccountID).

When the employee then re-submits offline, submitReport correctly computes the new managerID (the admin approver) via getSubmitReportManagerAccountID, but passes the stale expenseReport object (still containing managerID = employee) to buildOptimisticNextStep with isUnapprove: true.

Inside buildOptimisticNextStep, getNextApproverAccountID(report, true) takes the isUnapproved branch. Since the employee is not in the approval chain, it falls through to report?.managerID — which is the employee's own ID. This makes nextStep.actorAccountID equal to currentUserAccountID, so buildNextStepMessage renders "Waiting for you to approve" instead of the admin's name.

The correct managerID is only applied to the Onyx report data at line 1335, after the next step has already been built with the stale value.

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

Pass bypassNextApproverID: managerID to both buildOptimisticNextStep and buildNextStepNew calls in submitReport (ReportWorkflow.ts:1279-1300). The bypassNextApproverID parameter already exists on both functions and is used at NextStepUtils.ts:102 to override getNextApproverAccountID, which avoids the stale report.managerID entirely.

What alternative solutions did you explore? (Optional)

• Mutating the expenseReport object to set managerID before calling buildOptimisticNextStep — rejected because mutating the input parameter is fragile and could cause side effects.
• Removing isUnapprove: true from the submitReport call — rejected because isUnapprove may be intentionally needed for other scenarios where the approval chain is being reset.

---

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.

[KJ21-ENG]

Replaces my earlier proposal. The root cause and fix are unchanged; this edit refreshes the code anchors to current main and adds the current thread's bot/human proposal comparison in Alternatives.

Proposal

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

When an employee is offline and resubmits an expense report that was rejected back to them, the optimistic next-step message says the employee is waiting for themselves to approve the expenses.

The next-step actor should be the workspace approver/admin that the report is being submitted to.

What is the root cause of that problem?

Rejecting an expense report to the submitter intentionally moves the report back to open status and sets managerID to the submitter:

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

Lines 996 to 1020 in 053707d

	const optimisticNextStep = isRejectToSubmitter
	? buildOptimisticNextStep({
	report,
	predictedNextStatus: CONST.REPORT.STATUS_NUM.OPEN,
	isRejectedReport: true,
	})
	: buildOptimisticNextStep({
	report,
	predictedNextStatus: CONST.REPORT.STATUS_NUM.SUBMITTED,
	bypassNextApproverID: targetAccountID,
	});
	const optimisticData: Array<OnyxUpdate<typeof ONYXKEYS.COLLECTION.REPORT | typeof ONYXKEYS.COLLECTION.REPORT_ACTIONS | typeof ONYXKEYS.COLLECTION.NEXT_STEP>> = [
	{
	onyxMethod: Onyx.METHOD.MERGE,
	key: `${ONYXKEYS.COLLECTION.REPORT}${reportID}`,
	value: {
	managerID: targetAccountID,
	stateNum: optimisticStateNum,
	statusNum: optimisticStatusNum,
	pendingFields: {
	partial: CONST.RED_BRICK_ROAD_PENDING_ACTION.UPDATE,
	nextStep: CONST.RED_BRICK_ROAD_PENDING_ACTION.UPDATE,
	},
	nextStep: optimisticNextStep,

When the submitter later submits that rejected report offline, submitReport correctly recomputes the submit target via getSubmitReportManagerAccountID(...), stores it in managerID, sends it as managerAccountID, and writes that value into the optimistic report update:

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

Lines 1262 to 1263 in 053707d

	const managerID = getSubmitReportManagerAccountID(policy, expenseReport);
	const isCurrentUserManager = currentUserAccountIDParam === managerID;

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

Lines 1318 to 1342 in 053707d

	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,
	},
	}),

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

Lines 1504 to 1508 in 053707d

	const parameters: SubmitReportParams = {
	reportID: expenseReport.reportID,
	managerAccountID: managerID,
	reportActionID: optimisticSubmittedReportAction.reportActionID,
	};

However, both next-step builders are called before that optimistic report object exists, and they receive the original rejected expenseReport instead of a report with the newly computed manager. Because submitReport passes isUnapprove: true, getNextApproverAccountID(report, true) returns report.managerID before falling back to the policy submit target. For a reject-to-submitter report, that stale report.managerID is the employee:

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

Lines 1276 to 1300 in 053707d

	// 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,
	});

App/src/libs/NextStepUtils.ts

Lines 77 to 103 in 053707d

	function buildOptimisticNextStep(params: BuildNextStepNewParams): ReportNextStep | null {
	const {
	report,
	policy,
	currentUserAccountIDParam,
	currentUserEmailParam,
	hasViolations,
	isASAPSubmitBetaEnabled,
	predictedNextStatus,
	shouldFixViolations,
	isUnapprove,
	isReopen,
	isRejectedReport: isRejectedReportParam,
	bypassNextApproverID,
	} = params;
	if (!isExpenseReport(report)) {
	return null;
	}
	const {ownerAccountID = -1} = report ?? {};
	const autoReportingFrequency = getCorrectedAutoReportingFrequency(policy);
	const isInstantSubmitEnabled = autoReportingFrequency === CONST.POLICY.AUTO_REPORTING_FREQUENCIES.INSTANT;
	const shouldShowFixMessage = hasViolations && isInstantSubmitEnabled && !isASAPSubmitBetaEnabled;
	const hasTransactions = doesReportContainTransactions(report);
	const approverAccountID = bypassNextApproverID ?? getNextApproverAccountID(report, isUnapprove);
	const reimburserAccountID = getReimburserAccountID(policy);

App/src/libs/NextStepUtils.ts

Lines 456 to 498 in 053707d

	function buildNextStepNew(params: BuildNextStepNewParams): ReportNextStepDeprecated | null {
	const {
	report,
	policy,
	currentUserAccountIDParam,
	currentUserEmailParam,
	hasViolations,
	isASAPSubmitBetaEnabled,
	predictedNextStatus,
	shouldFixViolations,
	isUnapprove,
	isReopen,
	isRejectedReport,
	bypassNextApproverID,
	} = params;
	if (!isExpenseReport(report)) {
	return null;
	}
	const {ownerAccountID = -1} = report ?? {};
	const autoReportingFrequency = getCorrectedAutoReportingFrequency(policy);
	const isInstantSubmitEnabled = autoReportingFrequency === CONST.POLICY.AUTO_REPORTING_FREQUENCIES.INSTANT;
	const shouldShowFixMessage = hasViolations && isInstantSubmitEnabled && !isASAPSubmitBetaEnabled;
	const [policyOwnerPersonalDetails, ownerPersonalDetails] = getPersonalDetailsByIDs({
	accountIDs: [policy?.ownerAccountID ?? CONST.DEFAULT_NUMBER_ID, ownerAccountID],
	currentUserAccountID: currentUserAccountIDParam ?? CONST.DEFAULT_NUMBER_ID,
	shouldChangeUserDisplayName: true,
	});
	const hasTransactions = doesReportContainTransactions(report);
	const {reimbursableSpend} = getMoneyRequestSpendBreakdown(report);
	const ownerDisplayName =
	ownerPersonalDetails?.displayName ?? ownerPersonalDetails?.login ?? getDisplayNameForParticipant({accountID: ownerAccountID, formatPhoneNumber: formatPhoneNumberPhoneUtils});
	const policyOwnerDisplayName =
	policyOwnerPersonalDetails?.displayName ??
	policyOwnerPersonalDetails?.login ??
	getDisplayNameForParticipant({accountID: policy?.ownerAccountID, formatPhoneNumber: formatPhoneNumberPhoneUtils});
	const nextApproverDisplayName = bypassNextApproverID
	? (getDisplayNameForParticipant({accountID: bypassNextApproverID, formatPhoneNumber: formatPhoneNumberPhoneUtils}) ?? getPersonalDetailsForAccountID(bypassNextApproverID).login)
	: getNextApproverDisplayName(report, isUnapprove);
	const approverAccountID = bypassNextApproverID ?? getNextApproverAccountID(report, isUnapprove);
	const approvers = getLoginsByAccountIDs([approverAccountID ?? CONST.DEFAULT_NUMBER_ID]);

App/src/libs/ReportUtils.ts

Lines 4711 to 4730 in 053707d

	function getNextApproverAccountID(report: OnyxEntry<Report>, isUnapproved = false) {
	// This will be fixed as part of https://github.com/Expensify/Expensify/issues/507850
	const policy = getPolicy(report?.policyID);
	// If the current user took control, then they are the final approver and we don't have a next approver
	// If someone else took control or rerouted, they are the next approver
	const bypassApproverAccountID = getBypassApproverAccountIDIfTakenControl(report);
	if (bypassApproverAccountID) {
	return bypassApproverAccountID === deprecatedCurrentUserAccountID && !isUnapproved ? undefined : bypassApproverAccountID;
	}
	const approvalChain = getApprovalChain(policy, report);
	const submitToAccountID = getSubmitToAccountID(policy, report);
	if (isUnapproved) {
	if (approvalChain.includes(deprecatedCurrentUserEmail ?? '')) {
	return deprecatedCurrentUserAccountID;
	}
	return report?.managerID ?? submitToAccountID;

That stale actor is written into the new Report.nextStep. The translation layer then renders the WAITING_TO_APPROVE actor as "you" when actorAccountID matches the current employee:

App/src/libs/NextStepUtils.ts

Lines 47 to 70 in 053707d

	function buildNextStepMessage(nextStep: ReportNextStep, translate: LocaleContextProps['translate'], currentUserAccountID: number): string {
	// Escape actor name to prevent HTML injection since this will be rendered as HTML
	const actor = Str.safeEscape(getDisplayNameForParticipant({accountID: nextStep.actorAccountID, formatPhoneNumber: formatPhoneNumberPhoneUtils}) ?? '');
	let actorType: ValueOf<typeof CONST.NEXT_STEP.ACTOR_TYPE>;
	if (nextStep.actorAccountID === currentUserAccountID) {
	actorType = CONST.NEXT_STEP.ACTOR_TYPE.CURRENT_USER;
	} else if (nextStep.actorAccountID === -1) {
	actorType = CONST.NEXT_STEP.ACTOR_TYPE.UNSPECIFIED_ADMIN;
	} else {
	actorType = CONST.NEXT_STEP.ACTOR_TYPE.OTHER_USER;
	}
	let eta: string | undefined;
	let etaType: ValueOf<typeof CONST.NEXT_STEP.ETA_TYPE> | undefined;
	if (nextStep.eta?.etaKey) {
	eta = translate(`nextStep.eta.${nextStep.eta.etaKey}`);
	etaType = CONST.NEXT_STEP.ETA_TYPE.KEY;
	} else if (nextStep.eta?.dateTime) {
	const formatString = nextStep.messageKey === CONST.NEXT_STEP.MESSAGE_KEY.WAITING_FOR_AUTOMATIC_SUBMIT ? CONST.DATE.ORDINAL_DAY_OF_MONTH : CONST.DATE.LONG_DATE_FORMAT_WITH_WEEKDAY;
	eta = format(new Date(nextStep.eta.dateTime), formatString);
	etaType = CONST.NEXT_STEP.ETA_TYPE.DATE_TIME;
	}
	return `<next-step>${translate(`nextStep.message.${nextStep.messageKey}`, actor, actorType, eta, etaType)}</next-step>`;

App/src/libs/NextStepUtils.ts

Lines 218 to 225 in 053707d

	// We want to show pending approval next step for cases where the policy has approvals enabled
	const policyApprovalMode = getApprovalWorkflow(policy);
	if ([CONST.POLICY.APPROVAL_MODE.BASIC, CONST.POLICY.APPROVAL_MODE.ADVANCED].some((approvalMode) => approvalMode === policyApprovalMode)) {
	nextStep = {
	messageKey: CONST.NEXT_STEP.MESSAGE_KEY.WAITING_TO_APPROVE,
	icon: CONST.NEXT_STEP.ICONS.HOURGLASS,
	actorAccountID: approverAccountID,
	};

App/src/languages/en.ts

Lines 1882 to 1896 in 053707d

	[CONST.NEXT_STEP.MESSAGE_KEY.WAITING_TO_APPROVE]: (
	actor: string,
	actorType: ValueOf<typeof CONST.NEXT_STEP.ACTOR_TYPE>,
	_eta?: string,
	_etaType?: ValueOf<typeof CONST.NEXT_STEP.ETA_TYPE>,
	) => {
	// Disabling the default-case lint rule here is actually safer as this forces us to make the switch cases exhaustive
	// eslint-disable-next-line default-case
	switch (actorType) {
	case CONST.NEXT_STEP.ACTOR_TYPE.CURRENT_USER:
	return `Waiting for <strong>you</strong> to approve expenses.`;
	case CONST.NEXT_STEP.ACTOR_TYPE.OTHER_USER:
	return `Waiting for <strong>${actor}</strong> to approve expenses.`;
	case CONST.NEXT_STEP.ACTOR_TYPE.UNSPECIFIED_ADMIN:
	return `Waiting for an admin to approve expenses.`;

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

In submitReport, pass bypassNextApproverID: managerID to both buildNextStepNew(...) and buildOptimisticNextStep(...) in the non-DEW submit path. Keep using that same managerID for the optimistic report merge and SubmitReport API params. This makes the next-step actor come from the approver that submitReport already computed with getSubmitReportManagerAccountID(...), not from the rejected report's stale pre-submit managerID.

Add or update tests/actions/IOUTest/ReportWorkflowTest.ts with a reject-to-submitter style setup: an employee-owned open expense report has managerID equal to the employee, the policy routes the employee to an admin, and submitReport(...) is called as the employee/offline optimistic path. Assert that the SubmitReport params still use the admin as managerAccountID, the optimistic report update still uses that admin as managerID, and both the new Report.nextStep.actorAccountID and deprecated NEXT_STEP message point to the admin rather than the employee. This follows the existing API.write inspection pattern in the same test file.

Scope boundaries:

• Files touched: src/libs/actions/IOU/ReportWorkflow.ts - submitReport next-step builder inputs and existing optimistic report/API manager wiring.
• Tests touched: tests/actions/IOUTest/ReportWorkflowTest.ts - submit workflow regression coverage for rejected-to-submitter reports.
• Platforms: all platforms, because the bug is in shared optimistic Onyx data.
• Code paths explicitly not touched: rejectExpenseReport, getNextApproverAccountID, policy approval-chain resolution, DEW submit handling, display translations.
• API contracts or backend behavior changes: none.

What alternative solutions did you explore? (Optional)

I considered changing getNextApproverAccountID(report, true) to ignore report.managerID when it equals the report owner, but that helper is also used by approve, unapprove, assign, and add-approver flows. The narrower fix is to make submitReport pass the already-computed submit approver into the existing next-step builders.

MelvinBot identified the same stale report.managerID / missing bypassNextApproverID mechanism before my cached proposal was posted. I agree with that technical root cause; bot proposals do not create human duplicate pressure, and this proposal keeps the fix scoped to both next-step builders plus regression coverage.

The later human proposals from yusufdeveloper2903 and trasnake87 also point at the same submitReport next-step inputs. The only substantive variant is also passing report: {...expenseReport, managerID}; that is safe and matches nearby reassignment flows, but the displayed actor for this issue is already fixed by bypassNextApproverID because both builders use it for the approver account ID/name before falling back to report.managerID.

[melvin-bot]

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

[melvin-bot]

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

[yusufdeveloper2903]

Proposal

What is the root cause of that problem?

When the employee taps Submit on a previously-rejected expense report, submitReport builds the optimistic next-step with isUnapprove: true but does not pass a bypassNextApproverID:

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

Lines 1276 to 1300 in 053707d

	// 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,
	});

Inside buildOptimisticNextStep / buildNextStepNew, the approver who appears in the "Waiting for … to approve %expenses." copy is resolved through getNextApproverAccountID(report, /* isUnapproved */ true):

App/src/libs/NextStepUtils.ts

Lines 494 to 498 in 053707d

	const nextApproverDisplayName = bypassNextApproverID
	? (getDisplayNameForParticipant({accountID: bypassNextApproverID, formatPhoneNumber: formatPhoneNumberPhoneUtils}) ?? getPersonalDetailsForAccountID(bypassNextApproverID).login)
	: getNextApproverDisplayName(report, isUnapprove);
	const approverAccountID = bypassNextApproverID ?? getNextApproverAccountID(report, isUnapprove);
	const approvers = getLoginsByAccountIDs([approverAccountID ?? CONST.DEFAULT_NUMBER_ID]);

The isUnapproved branch in getNextApproverAccountID falls back to report.managerID whenever the current user isn't in the approval chain (which is the employee's situation):

App/src/libs/ReportUtils.ts

Lines 4725 to 4731 in 053707d

	if (isUnapproved) {
	if (approvalChain.includes(deprecatedCurrentUserEmail ?? '')) {
	return deprecatedCurrentUserAccountID;
	}
	return report?.managerID ?? submitToAccountID;
	}

The catch is that when the admin rejected back to the submitter, rejectMoneyRequest had already optimistically rewritten managerID to the rejected-to user (i.e. the employee's own ownerAccountID):

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

Lines 1008 to 1022 in 053707d

	const optimisticData: Array<OnyxUpdate<typeof ONYXKEYS.COLLECTION.REPORT | typeof ONYXKEYS.COLLECTION.REPORT_ACTIONS | typeof ONYXKEYS.COLLECTION.NEXT_STEP>> = [
	{
	onyxMethod: Onyx.METHOD.MERGE,
	key: `${ONYXKEYS.COLLECTION.REPORT}${reportID}`,
	value: {
	managerID: targetAccountID,
	stateNum: optimisticStateNum,
	statusNum: optimisticStatusNum,
	pendingFields: {
	partial: CONST.RED_BRICK_ROAD_PENDING_ACTION.UPDATE,
	nextStep: CONST.RED_BRICK_ROAD_PENDING_ACTION.UPDATE,
	},
	nextStep: optimisticNextStep,
	},
	},

So when submitReport reads expenseReport.managerID it sees the employee's accountID, getNextApproverAccountID echoes it back, nextApproverDisplayName becomes the current user's display name, and parseMessage then rewrites it to "you" — producing "Waiting for you to approve expenses". Online this is overwritten by the server's onyxData; offline only the (wrong) optimistic value is rendered, which matches the repro.

Note that the correct manager is already computed two lines above the broken call (getSubmitReportManagerAccountID looks the approver up from the policy, not from the stale report.managerID):

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

Line 1262 in 053707d

const managerID = getSubmitReportManagerAccountID(policy, expenseReport);

It just isn't threaded into the next-step builder.

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

Forward the already-computed managerID as bypassNextApproverID into both next-step builders in submitReport, so the optimistic copy uses the policy's actual approver instead of the stale report.managerID left over from the reject:

     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,
+              bypassNextApproverID: managerID,
           });
     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,
+              bypassNextApproverID: managerID,
           });

This is the same pattern that rejectMoneyRequest (bypassNextApproverID: targetAccountID,

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

Lines 996 to 1006 in 053707d

	const optimisticNextStep = isRejectToSubmitter
	? buildOptimisticNextStep({
	report,
	predictedNextStatus: CONST.REPORT.STATUS_NUM.OPEN,
	isRejectedReport: true,
	})
	: buildOptimisticNextStep({
	report,
	predictedNextStatus: CONST.REPORT.STATUS_NUM.SUBMITTED,
	bypassNextApproverID: targetAccountID,
	});

) and the retract/forward calls further down in ReportWorkflow.ts (

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

Lines 1525 to 1548 in 053707d

	// buildOptimisticNextStep is used in parallel
	const optimisticNextStepDeprecated = buildNextStepNew({
	report: {...report, managerID: accountID},
	predictedNextStatus: report.statusNum ?? CONST.REPORT.STATUS_NUM.SUBMITTED,
	shouldFixViolations: false,
	isUnapprove: true,
	policy,
	currentUserAccountIDParam: accountID,
	currentUserEmailParam: email,
	hasViolations,
	isASAPSubmitBetaEnabled,
	bypassNextApproverID: accountID,
	});
	const optimisticNextStep = buildOptimisticNextStep({
	report: {...report, managerID: accountID},
	predictedNextStatus: report.statusNum ?? CONST.REPORT.STATUS_NUM.SUBMITTED,
	shouldFixViolations: false,
	isUnapprove: true,
	policy,
	currentUserAccountIDParam: accountID,
	currentUserEmailParam: email,
	hasViolations,
	isASAPSubmitBetaEnabled,
	bypassNextApproverID: accountID,

) already use whenever report.managerID is known to be stale relative to the workflow the action is producing. managerID is already computed via getSubmitReportManagerAccountID(policy, expenseReport) on line 1262, so no new lookup is needed.

After this change, the offline optimistic message updates to "Waiting for [admin] to approve expenses" — and online behaviour is unchanged because the server response still wins.

What alternative solutions did you explore? (Optional)

1. Fix getNextApproverAccountID to ignore a report.managerID that equals ownerAccountID when isUnapproved is true. This would also work, but it changes a shared utility that's consumed by multiple flows (reject/unapprove/takeControl), so the blast radius is wider for what is really a submitReport-local problem. The bypassNextApproverID parameter exists precisely for this "I already know the right approver, ignore report.managerID" use case.
2. Drop isUnapprove: true in submitReport. With isUnapproved=false and an employee not in the approval chain, getNextApproverAccountID returns approvalChain.at(0) (the policy's first approver), which is also correct for this repro. But isUnapprove: true was added intentionally in PR #72892 to handle the case where an admin force-submits a report they themselves are part of the chain for, so removing it would regress that fix. Passing bypassNextApproverID instead keeps both paths happy.
3. Re-order the optimistic data so managerID is merged into the report before buildOptimisticNextStep runs. Doesn't help — the builders are called with the in-memory expenseReport object, not by re-reading Onyx, so a later Onyx.MERGE of managerID wouldn't affect the already-built nextStep.

[trasnake87]

Proposal

After an admin rejects an employee's report and the employee re-submits while offline, the optimistic next-step renders "Waiting for you to approve" instead of "Waiting for to approve".

Root cause

The reject flow correctly flips ownership back to the employee. In src/libs/actions/IOU/RejectMoneyRequest.ts:1006-1020, the optimistic Onyx update for a "reject to submitter" sets report.managerID to targetAccountID (the report's own ownerAccountID, i.e. the employee):

// src/libs/actions/IOU/RejectMoneyRequest.ts:1006-1020
const optimisticData = [
    {
        onyxMethod: Onyx.METHOD.MERGE,
        key: `${ONYXKEYS.COLLECTION.REPORT}${reportID}`,
        value: {
            managerID: targetAccountID,                  // employee's accountID
            stateNum: optimisticStateNum,                // OPEN
            statusNum: optimisticStatusNum,              // OPEN
            ...
            nextStep: optimisticNextStep,
        },
    },
    ...
];

When the employee then taps Submit while offline, submitReport in src/libs/actions/IOU/ReportWorkflow.ts:1239-1304 runs. It computes the new approver's managerID at line 1304 — but only after it has already built the optimistic next step at lines 1277-1302 from the stale expenseReport object (whose managerID is still the employee):

// src/libs/actions/IOU/ReportWorkflow.ts:1277-1304
// buildOptimisticNextStep is used in parallel
const optimisticNextStepDeprecated = isDEWPolicy
    ? null
    : // eslint-disable-next-line @typescript-eslint/no-deprecated
      buildNextStepNew({
          report: expenseReport,                         // stale: managerID = employee
          predictedNextStatus: isSubmitAndClosePolicy ? CONST.REPORT.STATUS_NUM.CLOSED : CONST.REPORT.STATUS_NUM.SUBMITTED,
          policy,
          currentUserAccountIDParam,
          currentUserEmailParam,
          hasViolations,
          isASAPSubmitBetaEnabled,
          isUnapprove: true,                             // takes the unapprove branch below
      });
const optimisticNextStep = isDEWPolicy
    ? null
    : buildOptimisticNextStep({
          report: expenseReport,                         // stale: managerID = employee
          predictedNextStatus: isSubmitAndClosePolicy ? CONST.REPORT.STATUS_NUM.CLOSED : CONST.REPORT.STATUS_NUM.SUBMITTED,
          policy,
          currentUserAccountIDParam,
          currentUserEmailParam,
          hasViolations,
          isASAPSubmitBetaEnabled,
          isUnapprove: true,
      });
const submitToAccountID = getSubmitToAccountID(policy, expenseReport);
const managerID = submitToAccountID > 0 ? submitToAccountID : expenseReport.managerID;

Inside buildOptimisticNextStep (src/libs/NextStepUtils.ts:77-102), the approver is resolved as:

// src/libs/NextStepUtils.ts:102
const approverAccountID = bypassNextApproverID ?? getNextApproverAccountID(report, isUnapprove);

Because no bypassNextApproverID is passed, it calls getNextApproverAccountID(report, true) in src/libs/ReportUtils.ts:4736-4757. With isUnapproved = true, control hits the fallback path because the employee is not in the policy's approval chain:

// src/libs/ReportUtils.ts:4748-4757
const approvalChain = getApprovalChain(policy, report);
const submitToAccountID = getSubmitToAccountID(policy, report);

if (isUnapproved) {
    if (approvalChain.includes(deprecatedCurrentUserEmail ?? '')) {
        return deprecatedCurrentUserAccountID;
    }

    return report?.managerID ?? submitToAccountID;      // returns stale employee accountID
}

The function returns report.managerID, which is still the employee's accountID from the reject step. That value then flows into buildNextStepMessage (src/libs/NextStepUtils.ts:47-71), where the equality check classifies the actor as CURRENT_USER:

// src/libs/NextStepUtils.ts:51-57
if (nextStep.actorAccountID === currentUserAccountID) {
    actorType = CONST.NEXT_STEP.ACTOR_TYPE.CURRENT_USER;       // "you"
} else if (nextStep.actorAccountID === -1) {
    actorType = CONST.NEXT_STEP.ACTOR_TYPE.UNSPECIFIED_ADMIN;
} else {
    actorType = CONST.NEXT_STEP.ACTOR_TYPE.OTHER_USER;
}

The message renders as "Waiting for you to approve". The corrected managerID (the admin) is only merged into the Onyx report at lines 1335-1346 — but by then the nextStep was already constructed from the stale value, and that pre-built nextStep is what gets written to Onyx at line 1343. So the wrong message persists until the request is replayed and the server returns fresh data.

Proposed fix

Reorder so the new managerID is computed first, then pass it as bypassNextApproverID to both buildNextStepNew and buildOptimisticNextStep. Replace src/libs/actions/IOU/ReportWorkflow.ts:1277-1304 with:

// src/libs/actions/IOU/ReportWorkflow.ts
const submitToAccountID = getSubmitToAccountID(policy, expenseReport);
const managerID = submitToAccountID > 0 ? submitToAccountID : expenseReport.managerID;

// buildOptimisticNextStep is used in parallel
const optimisticNextStepDeprecated = isDEWPolicy
    ? null
    : // eslint-disable-next-line @typescript-eslint/no-deprecated
      buildNextStepNew({
          report: {...expenseReport, managerID},
          predictedNextStatus: isSubmitAndClosePolicy ? CONST.REPORT.STATUS_NUM.CLOSED : CONST.REPORT.STATUS_NUM.SUBMITTED,
          policy,
          currentUserAccountIDParam,
          currentUserEmailParam,
          hasViolations,
          isASAPSubmitBetaEnabled,
          isUnapprove: true,
          bypassNextApproverID: managerID,
      });
const optimisticNextStep = isDEWPolicy
    ? null
    : buildOptimisticNextStep({
          report: {...expenseReport, managerID},
          predictedNextStatus: isSubmitAndClosePolicy ? CONST.REPORT.STATUS_NUM.CLOSED : CONST.REPORT.STATUS_NUM.SUBMITTED,
          policy,
          currentUserAccountIDParam,
          currentUserEmailParam,
          hasViolations,
          isASAPSubmitBetaEnabled,
          isUnapprove: true,
          bypassNextApproverID: managerID,
      });

Two changes per call site:

1. Pass bypassNextApproverID: managerID — short-circuits the stale-report branch in getNextApproverAccountID, so approverAccountID is the resolved admin instead of the rejected-back employee.
2. Replace report: expenseReport with report: {...expenseReport, managerID} — defends buildNextStepNew's display-name lookup at src/libs/NextStepUtils.ts:495-497 and the deprecated message rendering, both of which still read report.managerID in other code paths reachable from the same call (e.g. getNextApproverDisplayName).

Why this approach

The exact same pair-of-changes pattern is already the in-repo precedent for "we know the new approver before Onyx is updated" flows:

• assignReportToMe in src/libs/actions/IOU/ReportWorkflow.ts:1527-1554 passes both report: {...report, managerID: accountID} and bypassNextApproverID: accountID to buildNextStepNew and buildOptimisticNextStep.
• addReportApprover in src/libs/actions/IOU/ReportWorkflow.ts:1645-1665 does the same with newApproverAccountID.
• rejectMoneyRequest itself uses this technique at src/libs/actions/IOU/RejectMoneyRequest.ts:994-1004 and lines 1042-1054 — its non-submitter branch passes bypassNextApproverID: targetAccountID. The submit-after-reject path was simply never updated to match.

Fixing getNextApproverAccountID to ignore a self-managerID in the unapprove branch was considered and rejected: that function is also reached by code paths (e.g. assignReportToMe, addReportApprover) where report.managerID === currentUserAccountID is the correct answer (the user took control / became the approver), so changing it would regress those flows. Passing bypassNextApproverID at the call site is the same lever the rest of the codebase already uses for this class of bug and keeps the fix scoped to the one stale-managerID path.

[MobileMage]

🚫 Duplicated proposal withdrawn by 🤖 ProposalPolice.

[github-actions]

⚠️ @MobileMage 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.