[Due for payment 2026-08-05] [$250] Report - "What's next" does not update in real-time when report is approved while submitter is viewing

[yuwenmemon]

Description

When a report is approved (by an agent, or possibly any approver) while the submitter is actively viewing the report, the report action shows "approved" and the report header updates correctly — but the "What's next" section does not update.

Steps to Reproduce

1. Submitter opens and views a report
2. An agent (or approver) approves the report while the submitter is viewing it
3. Observe the report action shows "approved" and the header changes to reflect approval

Expected Result

The "What's next" section updates in real-time to reflect the new approval state, consistent with the report action and header.

Actual Result

The "What's next" section remains stale and does not update — even though the report action and header correctly reflect the approval.

Additional Context

• Example report: https://staging.new.expensify.com/e/7234182031034976
• Slack thread: https://expensify.slack.com/archives/C05LX9D6E07/p1779593119130849

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022058965872285777773
• Upwork Job ID: 2058965872285777773
• Last Price Increase: 2026-06-22

Issue Owner

Current Issue Owner: @suneox

[MelvinBot]

Proposal

What is the root cause of that problem?

The "What's next" bar is rendered by MoneyReportHeaderNextStep, which delegates to the useOptimisticNextStep hook. This hook reads from the deprecated ONYXKEYS.COLLECTION.NEXT_STEP Onyx collection (line 38) but never reads report.nextStep (the new ReportNextStep format embedded on the report object).

When the approver approves, approveMoneyRequest sets optimistic data on both report.nextStep (new) and ONYXKEYS.COLLECTION.NEXT_STEP (deprecated). But for the submitter viewing the report on a different client, only the server's Pusher update matters — and that update delivers the report object (with report.nextStep in the new format and updated statusNum) but does not update the separate deprecated NEXT_STEP collection.

The hook then calls getReportNextStep with the stale deprecated value. For typical expense reports with reimbursable spend > 0, the function falls through to return currentNextStep — the stale pre-approval message — because shouldShowNoFurtherAction is only true when reimbursableSpend === 0.

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

Update useOptimisticNextStep to also read moneyRequestReport.nextStep (the new ReportNextStep format from the report object). When the new-format nextStep is present on the report and its state is more recent than the deprecated collection value, prefer it. This ensures the Pusher-delivered report.nextStep is consumed by the rendering pipeline.

Alternatively, update getReportNextStep to compute the correct next step based on the report's current statusNum when the report is in an approved/reimbursed state with reimbursable spend, rather than falling through to the stale currentNextStep.

What alternative solutions did you explore? (Optional)

An alternative would be to ensure the server's Pusher response for ApproveMoneyRequest includes an update to the deprecated ONYXKEYS.COLLECTION.NEXT_STEP collection. However, since the codebase is migrating from the deprecated format to the new report.nextStep format, the better long-term fix is to have the client read the new format rather than extending the lifecycle of the deprecated data path.

---

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.

[dilshodmackbook-sketch]

Proposal

What is the root cause of that problem?

getReportNextStep short-circuits to the stale server-side currentNextStep for approved reports when there's any reimbursable spend. The "no further action" branch only fires when reimbursableSpend === 0:

https://github.com/Expensify/App/blob/main/src/libs/NextStepUtils.ts#L367-L401

const {reimbursableSpend} = getMoneyRequestSpendBreakdown(moneyRequestReport);
const shouldShowNoFurtherAction =
    reimbursableSpend === 0 &&
    (moneyRequestReport?.statusNum === CONST.REPORT.STATUS_NUM.APPROVED ||
        (moneyRequestReport?.statusNum === CONST.REPORT.STATUS_NUM.SUBMITTED && policy?.approvalMode === CONST.POLICY.APPROVAL_MODE.OPTIONAL));
...
if (shouldShowNoFurtherAction) {
    return buildNextStepNew({...});
}

return currentNextStep;

The repro flow:

1. Submitter is viewing a report with statusNum = SUBMITTED. currentNextStep from Onyx is the "Waiting for approver" message produced when the report was first submitted.
2. Approver runs MarkReportApproved on a different device. Server flips statusNum → APPROVED and pushes the new report state via Pusher.
3. Submitter's client receives the REPORT update. Header re-renders correctly (it reads from moneyRequestReport.statusNum). The report action also re-renders correctly (driven by the new REPORT_ACTIONS entry).
4. useOptimisticNextStep re-runs because deps changed (moneyRequestReport updated). It calls getReportNextStep. reimbursableSpend > 0 (the report has real expenses), so shouldShowNoFurtherAction = false. The function returns currentNextStep — which is still the "Waiting for approver" message that hasn't been refreshed via Pusher.

The server-side NEXT_STEP Onyx key doesn't get pushed to the submitter on a state transition driven by another device. Only the entity that originated the change gets NEXT_STEP in its successData. So the submitter's local currentNextStep stays stale until the next OpenReport or full reconnect.

buildNextStepNew is already capable of producing the correct "approved, awaiting reimbursement" / "approved, no further action" messages from the new statusNum — it just isn't called for approved-with-spend reports.

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

Drop the reimbursableSpend === 0 clause from shouldShowNoFurtherAction so any status-transition into APPROVED regenerates the next-step message client-side from the current state, rather than relying on a server-side NEXT_STEP update that the submitter never received:

  const {reimbursableSpend} = getMoneyRequestSpendBreakdown(moneyRequestReport);
- const shouldShowNoFurtherAction =
-     reimbursableSpend === 0 &&
-     (moneyRequestReport?.statusNum === CONST.REPORT.STATUS_NUM.APPROVED ||
-         (moneyRequestReport?.statusNum === CONST.REPORT.STATUS_NUM.SUBMITTED && policy?.approvalMode === CONST.POLICY.APPROVAL_MODE.OPTIONAL));
+ const isApprovedOrAutoApproved =
+     moneyRequestReport?.statusNum === CONST.REPORT.STATUS_NUM.APPROVED ||
+     (moneyRequestReport?.statusNum === CONST.REPORT.STATUS_NUM.SUBMITTED && policy?.approvalMode === CONST.POLICY.APPROVAL_MODE.OPTIONAL);
+ // Recompute the next step from the current report state for approved reports regardless of
+ // reimbursable spend. The reimbursableSpend === 0 gate was leaking a stale `currentNextStep`
+ // from before the approval when the submitter was on another device during the approval.
+ const shouldShowNoFurtherAction = reimbursableSpend === 0 && isApprovedOrAutoApproved;
+ const shouldRecomputeForApproval = isApprovedOrAutoApproved;
  ...
- if (shouldShowNoFurtherAction) {
+ if (shouldShowNoFurtherAction || shouldRecomputeForApproval) {
      return buildNextStepNew({
          report: moneyRequestReport,
          policy,
          currentUserAccountIDParam: currentUserAccountID,
          currentUserEmailParam: currentUserEmail,
          hasViolations: false,
          isASAPSubmitBetaEnabled: false,
          predictedNextStatus: moneyRequestReport?.statusNum ?? CONST.REPORT.STATUS_NUM.OPEN,
      });
  }

buildNextStepNew already handles the APPROVED-with-spend case correctly (it produces "Waiting for reimbursement" or "No further action" depending on the policy's reimbursement settings, using the current statusNum). After this, the submitter's "What's next" recomputes locally the moment the REPORT entry's statusNum flips to APPROVED via Pusher — matching the header's behavior.

Alternative narrower fix: keep the existing shouldShowNoFurtherAction gate, but add an else if for approved-with-spend that also calls buildNextStepNew. Result is the same — the wider gate is just cleaner.

What alternative solutions did you explore?

N/A

[KJ21-ENG]

🚨 Edited by proposal-police: This proposal was edited at 2026-05-25 17:50:46 UTC.

Proposal

Replaces my earlier proposal. This version calls out both stale read paths: useOptimisticNextStep ignores the live report.nextStep field, and getReportNextStep can still let a stale deprecated reportNextStep_ value win after the report status has moved to approved. The fix makes the report-embedded next step and current report status authoritative, while keeping the deprecated collection only as a fallback during migration.

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

When a submitter is already viewing an expense report and another user approves it, the report action stream and report header update to the approved state, but the "What's next" section can keep showing the old submitted-state message, such as waiting for the approver to approve.

What is the root cause of that problem?

MoneyReportHeaderNextStep renders the value returned by useOptimisticNextStep(reportID).

App/src/components/MoneyReportHeaderNextStep.tsx

Lines 17 to 27 in 95ebf57

	function MoneyReportHeaderNextStep({reportID}: MoneyReportHeaderNextStepProps) {
	const {isOffline} = useNetwork();
	const [reportLoadingState] = useOnyx(`${ONYXKEYS.COLLECTION.RAM_ONLY_REPORT_LOADING_STATE}${reportID}`);
	const isLoadingInitialReportActions = reportLoadingState?.isLoadingInitialReportActions;
	const optimisticNextStep = useOptimisticNextStep(reportID);
	const showNextStepBar = !!optimisticNextStep && (('message' in optimisticNextStep && !!optimisticNextStep.message?.length) || 'messageKey' in optimisticNextStep);
	const showNextStepSkeleton = !optimisticNextStep && !!isLoadingInitialReportActions && !isOffline;
	if (showNextStepBar) {
	return <MoneyReportHeaderStatusBar nextStep={optimisticNextStep} />;

useOptimisticNextStep subscribes to the live report, but the next-step payload it passes into getReportNextStep still comes from the deprecated standalone ONYXKEYS.COLLECTION.NEXT_STEP / reportNextStep_ collection. It does not prefer moneyRequestReport.nextStep.

App/src/hooks/useOptimisticNextStep.ts

Lines 36 to 60 in 95ebf57

	const [moneyRequestReport] = useOnyx(`${ONYXKEYS.COLLECTION.REPORT}${reportID}`);
	const [policy] = useOnyx(`${ONYXKEYS.COLLECTION.POLICY}${getNonEmptyStringOnyxID(moneyRequestReport?.policyID)}`);
	const [nextStep] = useOnyx(`${ONYXKEYS.COLLECTION.NEXT_STEP}${moneyRequestReport?.reportID}`);
	const [reportMetadata] = useOnyx(`${ONYXKEYS.COLLECTION.REPORT_METADATA}${moneyRequestReport?.reportID}`);
	const [allTransactionViolations] = useOnyx(ONYXKEYS.COLLECTION.TRANSACTION_VIOLATIONS);
	const {reportActions: unfilteredReportActions} = usePaginatedReportActions(moneyRequestReport?.reportID);
	const reportActions = getFilteredReportActionsForReportView(unfilteredReportActions);
	const {transactions: reportTransactions, violations} = useTransactionsAndViolationsForReport(moneyRequestReport?.reportID);
	const transactions = Object.values(reportTransactions);
	const isArchivedReport = useReportIsArchived(moneyRequestReport?.reportID);
	const isDEWPolicy = hasDynamicExternalWorkflow(policy);
	const isBlockSubmitDueToStrictPolicyRules = shouldBlockSubmitDueToStrictPolicyRules(
	moneyRequestReport?.reportID,
	violations,
	areStrictPolicyRulesEnabled,
	accountID,
	email ?? '',
	transactions,
	);
	let optimisticNextStep = getReportNextStep(nextStep, moneyRequestReport, transactions, policy, allTransactionViolations, email ?? '', accountID);

That matters because this area is mid-migration. Report already has the newer nextStep field, and the local approve path writes both the report-embedded nextStep and the deprecated reportNextStep_ key.

App/src/types/onyx/Report.ts

Lines 287 to 288 in 95ebf57

	/** The report's next step */
	nextStep?: ReportNextStep;

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

Lines 473 to 524 in 95ebf57

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

So the approver's device can look correct from optimistic data, while a submitter who is only receiving real-time updates can have fresh report.statusNum, fresh report actions, and possibly fresh report.nextStep, but still retain the old deprecated reportNextStep_ payload.

getReportNextStep then preserves that stale value for the normal reimbursable approved case. Its approved-state recompute branch only runs when reimbursableSpend === 0; otherwise it falls through to return currentNextStep.

App/src/libs/NextStepUtils.ts

Lines 358 to 404 in 95ebf57

	function getReportNextStep(
	currentNextStep: ReportNextStepDeprecated | undefined,
	moneyRequestReport: OnyxEntry<Report>,
	transactions: Array<OnyxEntry<Transaction>>,
	policy: OnyxEntry<Policy>,
	transactionViolations: OnyxCollection<TransactionViolations>,
	currentUserEmail: string,
	currentUserAccountID: number,
	) {
	const {reimbursableSpend} = getMoneyRequestSpendBreakdown(moneyRequestReport);
	const shouldShowNoFurtherAction =
	reimbursableSpend === 0 &&
	(moneyRequestReport?.statusNum === CONST.REPORT.STATUS_NUM.APPROVED ||
	(moneyRequestReport?.statusNum === CONST.REPORT.STATUS_NUM.SUBMITTED && policy?.approvalMode === CONST.POLICY.APPROVAL_MODE.OPTIONAL));
	if (
	isOpenExpenseReport(moneyRequestReport) &&
	transactions.length > 0 &&
	transactions.every(
	(transaction) => !!transaction && hasSubmissionBlockingViolations(transaction, transactionViolations, currentUserEmail, currentUserAccountID, moneyRequestReport, policy),
	)
	) {
	// eslint-disable-next-line rulesdir/no-default-id-values -- actorAccountID can be -1 for unspecified owner
	return buildOptimisticFixIssueNextStep(moneyRequestReport?.ownerAccountID ?? -1);
	}
	// When prevent self-approval is enabled & the current user is submitter AND they're submitting to themselves, we need to show the optimistic next step
	// We should always show this optimistic message for policies with preventSelfApproval
	// to avoid any flicker during transitions between online/offline states
	if (shouldBlockSubmitDueToPreventSelfApproval(moneyRequestReport, policy)) {
	return buildOptimisticNextStepForPreventSelfApprovalsEnabled();
	}
	if (shouldShowNoFurtherAction) {
	return buildNextStepNew({
	report: moneyRequestReport,
	policy,
	currentUserAccountIDParam: currentUserAccountID,
	currentUserEmailParam: currentUserEmail,
	hasViolations: false,
	isASAPSubmitBetaEnabled: false,
	predictedNextStatus: moneyRequestReport?.statusNum ?? CONST.REPORT.STATUS_NUM.OPEN,
	});
	}
	return currentNextStep;
	}

That fallback disagrees with the existing status builders. They already know that approved non-payers should see no further action, while the payer/admin still sees the pay or bank-account next step when appropriate.

App/src/libs/NextStepUtils.ts

Lines 246 to 259 in 95ebf57

	// Generates an optimistic nextStep once a report has been approved
	case CONST.REPORT.STATUS_NUM.APPROVED:
	if (isInvoiceReport(report) || !isPayer(currentUserAccountIDParam, currentUserEmailParam, report, undefined) || reimbursableSpend === 0) {
	nextStep = nextStepNoActionRequired;
	break;
	}
	// Self review
	nextStep = {
	messageKey: hasValidAccount ? CONST.NEXT_STEP.MESSAGE_KEY.WAITING_TO_PAY : CONST.NEXT_STEP.MESSAGE_KEY.WAITING_FOR_POLICY_BANK_ACCOUNT,
	icon: CONST.NEXT_STEP.ICONS.HOURGLASS,
	actorAccountID: reimburserAccountID,
	};
	break;

App/src/libs/NextStepUtils.ts

Lines 787 to 823 in 95ebf57

	// Generates an optimistic nextStep once a report has been approved
	case CONST.REPORT.STATUS_NUM.APPROVED: {
	if (isInvoiceReport(report) || !isPayer(currentUserAccountIDParam, currentUserEmailParam, report, undefined) || reimbursableSpend === 0) {
	optimisticNextStep = noActionRequired;
	break;
	}
	// Self review
	let payerMessage: Message;
	if (isPayer(currentUserAccountIDParam, currentUserEmailParam, report, undefined)) {
	payerMessage = {text: 'you', type: 'strong'};
	} else if (reimburserAccountID === -1) {
	payerMessage = {text: 'an admin'};
	} else {
	payerMessage = {text: getDisplayNameForParticipant({accountID: reimburserAccountID, formatPhoneNumber: formatPhoneNumberPhoneUtils}), type: 'strong'};
	}
	optimisticNextStep = {
	type,
	icon: CONST.NEXT_STEP.ICONS.HOURGLASS,
	message: [
	{
	text: 'Waiting for ',
	},
	payerMessage,
	{
	text: ' to ',
	},
	{
	text: 'pay',
	},
	{
	text: ' %expenses.',
	},
	],
	};
	break;

So the stale banner is not a header rendering problem. The read path trusts the deprecated next-step collection after the report object has already proven the workflow moved on.

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

Update the next-step read path so current report data wins over stale deprecated data.

1. Widen the next-step value handled by getReportNextStep to ReportNextStep | ReportNextStepDeprecated | undefined. MoneyReportHeaderNextStep and MoneyReportHeaderStatusBar already support both shapes, so this is mostly a typing/read-path change.

2. In useOptimisticNextStep, pass the report-embedded next step first and keep the deprecated collection as a migration fallback:

const currentNextStep = moneyRequestReport?.nextStep ?? nextStep;
let optimisticNextStep = getReportNextStep(
    currentNextStep,
    moneyRequestReport,
    transactions,
    policy,
    allTransactionViolations,
    email ?? '',
    accountID,
);

3. In getReportNextStep, keep the existing special optimistic overrides first, such as submission-blocking violations and prevent-self-approval. After those checks, derive from moneyRequestReport.statusNum for states where the old "waiting to approve" message is incompatible with the live report state: APPROVED, CLOSED, REIMBURSED, and submitted optional-approval reports.

For those current states, call the existing builder with predictedNextStatus: moneyRequestReport.statusNum instead of returning currentNextStep. That keeps the existing approved-state rules in one place:

• submitters and other non-payers on approved reports get NO_FURTHER_ACTION
• payers on reimbursable approved reports still get WAITING_TO_PAY or WAITING_FOR_POLICY_BANK_ACCOUNT
• closed and reimbursed reports show no further action
• zero-total and optional-approval cases continue to use the existing no-action/pay behavior

Only after the report-embedded next step and current-status fallback have been considered should getReportNextStep return the deprecated reportNextStep_ value.

I would not rely only on pushing a fresh reportNextStep_ key from the backend. That extends a deprecated collection and still leaves the client vulnerable to stale standalone data winning over the report object. I also would not drop the deprecated fallback yet because several local optimistic/DEW/strict-rule paths still emit the deprecated shape while the migration is in progress.

What specific scenarios should we cover in automated tests to prevent reintroducing this issue in the future?

Add focused coverage in tests/unit/NextStepUtilsTest.ts for the stale remote-approval state:

1. Build a submitted reimbursable report with a deprecated current next step that says "Waiting for approver to approve".
2. Change the report to stateNum: APPROVED and statusNum: APPROVED without changing the deprecated next-step payload.
3. Call getReportNextStep() as the submitter/non-payer.
4. Assert that the returned next step is no further action, not the stale waiting-to-approve payload.

Add a companion approved payer/admin case so the fix does not incorrectly show no further action when the current user still needs to pay or add a policy bank account.

Manual regression:

1. Submitter opens a submitted report.
2. Approver approves the report from another account/session.
3. Confirm the submitter sees the approved report action, approved header, and updated "What's next" section without refreshing.

[melvin-bot]

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

[wildan-m]

🚫 Duplicated proposal withdrawn by 🤖 ProposalPolice.

[aswin-s]

Proposal

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

When a report is approved by an approver/agent while the submitter is actively viewing it, the report action ("approved") and the report header update in real time, but the "What's next" status bar stays stale (e.g. keeps showing "Waiting for to approve"). Expected: "What's next" updates in real time to reflect the approved state, consistent with the header and the report action.

What is the root cause of that problem?

The "What's next" bar is rendered by MoneyReportHeaderNextStep, which delegates to useOptimisticNextStep. That hook computes the displayed value via getReportNextStep:

// src/hooks/useOptimisticNextStep.ts:58
let optimisticNextStep = getReportNextStep(nextStep, moneyRequestReport, transactions, policy, allTransactionViolations, email ?? '', accountID);

getReportNextStep (src/libs/NextStepUtils.ts:358-404) only recomputes the step from the report's current status when shouldShowNoFurtherAction is true, and that flag is gated behind reimbursableSpend === 0:

// src/libs/NextStepUtils.ts:367-371
const {reimbursableSpend} = getMoneyRequestSpendBreakdown(moneyRequestReport);
const shouldShowNoFurtherAction =
    reimbursableSpend === 0 &&
    (moneyRequestReport?.statusNum === CONST.REPORT.STATUS_NUM.APPROVED ||
        (moneyRequestReport?.statusNum === CONST.REPORT.STATUS_NUM.SUBMITTED && policy?.approvalMode === CONST.POLICY.APPROVAL_MODE.OPTIONAL));
...
// src/libs/NextStepUtils.ts:391-403
if (shouldShowNoFurtherAction) {
    return buildNextStepNew({ report: moneyRequestReport, policy, ..., predictedNextStatus: moneyRequestReport?.statusNum ?? CONST.REPORT.STATUS_NUM.OPEN });
}
return currentNextStep;

Repro path:

1. Submitter is viewing a report with statusNum = SUBMITTED. currentNextStep (the deprecated ONYXKEYS.COLLECTION.NEXT_STEP value) is the "Waiting for to approve" message written when the report was submitted.
2. The approver approves on another device. The server flips statusNum/stateNum → APPROVED and pushes the updated report to the submitter over Pusher — which is why the header and the report action update.
3. The optimistic NEXT_STEP write only happens inside the approver's own approveMoneyRequest flow; the submitter never runs that action, so their cached NEXT_STEP is never refreshed.
4. useOptimisticNextStep re-runs (the report dep changed) and calls getReportNextStep. The report has real expenses, so reimbursableSpend > 0, shouldShowNoFurtherAction is false, and the function falls through to return currentNextStep — the stale pre-approval message.

So the next-step value is fully derivable from the now-pushed statusNum, but the reimbursableSpend === 0 gate prevents that recompute for any approved report that actually has reimbursable spend (the common case).

Note the cached currentNextStep is a ReportNextStepDeprecated (src/types/onyx/ReportNextStepDeprecated.ts:57-94) — an icon/type/message shape that carries no statusNum. There is therefore nothing on the cached value to "compare" the report's status against; the correct fix is to recompute unconditionally for terminal statuses, not to diff against the cache.

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

In getReportNextStep (src/libs/NextStepUtils.ts:367-403), stop gating the recompute on reimbursableSpend === 0. The next step for a report in a terminal/approved status is fully determined by the report's current statusNum, so recompute from it via buildNextStepNew instead of returning the cached value:

- const {reimbursableSpend} = getMoneyRequestSpendBreakdown(moneyRequestReport);
- const shouldShowNoFurtherAction =
-     reimbursableSpend === 0 &&
-     (moneyRequestReport?.statusNum === CONST.REPORT.STATUS_NUM.APPROVED ||
-         (moneyRequestReport?.statusNum === CONST.REPORT.STATUS_NUM.SUBMITTED && policy?.approvalMode === CONST.POLICY.APPROVAL_MODE.OPTIONAL));
+ // The next step for an approved report (or a submitted report under optional approval) is fully
+ // determined by the report's current status, so always recompute it from that status rather than
+ // trusting the cached deprecated value. When a third party approves while the submitter is only
+ // viewing, the submitter's NEXT_STEP is never refreshed (only the approver's client writes it),
+ // so the cached value goes stale even though statusNum has flipped to APPROVED over Pusher.
+ const shouldRecomputeFromStatus =
+     moneyRequestReport?.statusNum === CONST.REPORT.STATUS_NUM.APPROVED ||
+     (moneyRequestReport?.statusNum === CONST.REPORT.STATUS_NUM.SUBMITTED && policy?.approvalMode === CONST.POLICY.APPROVAL_MODE.OPTIONAL);
  ...
- if (shouldShowNoFurtherAction) {
+ if (shouldRecomputeFromStatus) {
      return buildNextStepNew({
          report: moneyRequestReport,
          policy,
          currentUserAccountIDParam: currentUserAccountID,
          currentUserEmailParam: currentUserEmail,
          hasViolations: false,
          isASAPSubmitBetaEnabled: false,
          predictedNextStatus: moneyRequestReport?.statusNum ?? CONST.REPORT.STATUS_NUM.OPEN,
      });
  }
  return currentNextStep;

Why this is safe and complete:

• buildNextStepNew's APPROVED branch already produces the correct message for every viewer regardless of spend: invoice reports, non-payers, and zero-spend reports get "No further action required!", while the payer of a reimbursable approved report gets "Waiting for you/ to pay". This is the exact same builder approveMoneyRequest uses to set the approver's own optimistic next step, so the viewer simply becomes consistent with the approver.
• The SUBMITTED clause stays gated on approvalMode === OPTIONAL, so submitted reports under basic/advanced approval are untouched — they still return the cached "Waiting for to approve" value, which is correct.
• getReportNextStep has a single production consumer (useOptimisticNextStep), and that hook already re-renders reactively via useOnyx on report-status changes, so no change is needed in the hook or in MoneyReportHeaderNextStep.

Add unit coverage in tests/unit/NextStepUtilsTest.ts: a submitted reimbursable report whose deprecated currentNextStep is the stale "Waiting to approve" message should, once statusNum becomes APPROVED, return No further action required! for a submitter/non-payer and "Waiting … to pay" for the payer — guarding both the fix and the payer path against regression.

What alternative solutions did you explore? (Optional)

• Read the new report.nextStep format in useOptimisticNextStep instead (have the hook prefer the Pusher-delivered embedded nextStep over the deprecated collection). Rejected: this broadens the change into the deprecated→new nextStep migration and still depends on the server populating that field on the pushed report; recomputing from statusNum — which already arrives and already drives the header — is smaller, fully client-derivable, and keeps all next-step logic in one place.
• Diff the report's statusNum against "what the cached currentNextStep represents". Rejected: ReportNextStepDeprecated carries no status, so there is nothing to compare against; recomputing unconditionally for terminal statuses is the correct and implementable form.
• Have the backend push a fresh NEXT_STEP to the submitter on third-party approval. Rejected: requires a backend change and extends the lifecycle of the deprecated data path the codebase is migrating away from; the client already has enough state to derive the value.

[melvin-bot]

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