[$250] Bug: Approve button flickers (disappears, reappears, disappears) when approving a report from workspace chat report preview

[melvin-bot]

Description

When approving a report from the workspace chat report preview, the approve button flickers — it disappears, reappears, then disappears again instead of cleanly transitioning away after the action.

Steps to reproduce

1. Open a workspace chat report preview for a report that is pending approval.
2. Tap/click the Approve button.
3. Observe the button: it disappears, briefly reappears, then disappears again.

Expected behavior

The approve button should disappear cleanly (once) after tapping, as the report transitions to an approved state.

Actual behavior

The approve button disappears, reappears momentarily, then disappears again — a visible flicker.

Notes from investigation

• Reproduced on a normal workspace; could not reproduce on the DEW policy.
• Not consistently reproducible across all reports in a workspace.
• Suspected cause: the Onyx update for the report status may be racing with the animation/UI timeout — the optimistic update may not always fire fast enough (or is being overwritten/re-evaluated) before the button re-renders.

Platform

• Android
• iOS
• Web
• Desktop

Issue Owner

Current Issue Owner: @KJ21-ENG

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022064334100606413565
• Upwork Job ID: 2064334100606413565
• Last Price Increase: 2026-06-09

[MelvinBot]

Proposal

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

Approving a report from the workspace chat report preview makes the action button flicker — it disappears, briefly reappears, then disappears again instead of transitioning away cleanly. It reproduces only on normal workspaces (not DEW) and only intermittently.

What is the root cause of that problem?

There are two independent conditions that drive which button the preview shows, and on approval they flip in separate render commits, leaving a one-frame gap where neither is active.

When you press Approve, approveMoneyRequest does two things:

1. Calls onApproved?.() → startApprovedAnimation() → sets the React state isApprovedAnimationRunning = true.
2. Calls API.write(...) with optimisticData that flips the report to APPROVED (stateNum/statusNum).

The displayed button is chosen by getReportPreviewAction:

• If isApprovedAnimationRunning is true → returns PAY (renders the AnimatedSettlementButton).
• Otherwise it evaluates canApprove, which requires isProcessingReport (stateNum === SUBMITTED && statusNum === SUBMITTED).

The two state sources update through different channels — the React flag via setState, the report status via Onyx's async broadcast — so their commits can interleave. When the optimistic Onyx update lands in a render before the animation flag does, that intermediate render has canApprove === false (report is now APPROVED) and isApprovedAnimationRunning === false, so the action falls through to PAY/VIEW and the green Approve button vanishes. The next render applies the animation flag → the animated button reappears, then onAnimationFinish → stopAnimation clears it and it settles away. That is the disappear → reappear → disappear flicker.

This matches both reported quirks:

• No flicker on DEW — DEW skips the optimistic stateNum/statusNum update, so canApprove never flips out from under the animation; the animation flag is the only driver and the transition stays smooth.
• Intermittent — it's a render-ordering race; sometimes the flag commits first (smooth), sometimes the Onyx update does (flicker).

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

Eliminate the gap between "approve condition true" and "animation flag true" so the slot is never empty:

• Set the animation flag synchronously relative to the optimistic Onyx write so the flag-driven render always commits first — e.g. wrap startApprovedAnimation() in ReactDOM.flushSync (or flush it before calling API.write), guaranteeing the PAY/animated-button render lands before the report-status change can.
• Or close the gap in getReportPreviewAction: keep returning the animated button for a report that just became APPROVED until the animation completes, rather than depending solely on the React flag winning the race.

A maintainer should confirm the exact scheduling with a local repro before settling on the approach.

Confidence & verification notes

Confidence: Medium. The trigger (optimistic stateNum/statusNum flip) is confirmed by code and corroborated by the DEW non-repro. The mechanism (getReportPreviewAction switching between canApprove and isApprovedAnimationRunning, rendered by two different button components — plain ApproveActionButton vs animated PayActionButton) is confirmed by code. The exact render-timing interleave that loses the race is the one piece not yet confirmed at runtime — worth verifying with React profiler / Onyx update logging in a local repro before implementing.

---

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

[mukhrr]

🚨 Edited by proposal-police: This proposal was edited at 2026-06-09 13:11:08 UTC.

Proposal

What is the root cause of that problem?

The workspace chat report preview can re-enable the Approve action after the local approved animation finishes because the preview only suppresses approval from report state or DEW-only pending metadata.

In ReportPreviewActionUtils.canApprove(), the preview returns APPROVE when the report is still processing, approval is enabled, current user is the manager, and the report has transactions. The only pending-approve guard is hasPendingDEWApprove(), which explicitly ignores non-DEW policies:

• Preview approve eligibility:

  App/src/libs/ReportPreviewActionUtils.ts

  Lines 63 to 92 in 1cd4070

  	function canApprove(report: Report, currentUserAccountID: number, reportMetadata: OnyxEntry<ReportMetadata>, policy?: Policy, transactions?: Transaction[]) {
  	const isExpense = isExpenseReport(report);
  	const isProcessing = isProcessingReport(report);
  	const isApprovalEnabled = policy?.approvalMode && policy.approvalMode !== CONST.POLICY.APPROVAL_MODE.OPTIONAL;
  	const managerID = report.managerID ?? CONST.DEFAULT_NUMBER_ID;
  	const isCurrentUserManager = managerID === currentUserAccountID;
  	const reportTransactions = transactions ?? getReportTransactions(report?.reportID);
  	const isAnyReceiptBeingScanned = transactions?.some((transaction) => isScanning(transaction));
  	if (isAnyReceiptBeingScanned) {
  	return false;
  	}
  	if (reportTransactions.length > 0 && reportTransactions.every((transaction) => isPending(transaction))) {
  	return false;
  	}
  	const isDEWPolicy = hasDynamicExternalWorkflow(policy);
  	if (hasPendingDEWApprove(reportMetadata, isDEWPolicy)) {
  	return false;
  	}
  	const isPreventSelfApprovalEnabled = policy?.preventSelfApproval;
  	const isReportSubmitter = isCurrentUserSubmitter(report);
  	if (isPreventSelfApprovalEnabled && isReportSubmitter) {
  	return false;
  	}
  	return isExpense && isProcessing && !!isApprovalEnabled && reportTransactions.length > 0 && isCurrentUserManager;

• Preview action selection returns APPROVE after animation stops:

  App/src/libs/ReportPreviewActionUtils.ts

  Lines 224 to 245 in 1cd4070

  	// We want to have action displayed for either paid or approved animations
  	if (isPaidAnimationRunning || isApprovedAnimationRunning) {
  	return CONST.REPORT.REPORT_PREVIEW_ACTIONS.PAY;
  	}
  	if (isSubmittingAnimationRunning) {
  	return CONST.REPORT.REPORT_PREVIEW_ACTIONS.SUBMIT;
  	}
  	if (isAddExpenseAction(report, transactions ?? [], isReportArchived)) {
  	return CONST.REPORT.REPORT_PREVIEW_ACTIONS.ADD_EXPENSE;
  	}
  	if (isDEWSubmitPending && isOpenReport(report)) {
  	return CONST.REPORT.REPORT_PREVIEW_ACTIONS.VIEW;
  	}
  	if (canSubmit(report, isReportArchived, currentUserAccountID, currentUserLogin, violationsData, policy, transactions)) {
  	return CONST.REPORT.REPORT_PREVIEW_ACTIONS.SUBMIT;
  	}
  	if (canApprove(report, currentUserAccountID, reportMetadata, policy, transactions)) {
  	return CONST.REPORT.REPORT_PREVIEW_ACTIONS.APPROVE;

• DEW-only pending approve helper:

  App/src/libs/ReportActionsUtils.ts

  Lines 389 to 390 in 1cd4070

  	function hasPendingDEWApprove(reportMetadata: OnyxEntry<ReportMetadata>, isDEWPolicy: boolean): boolean {
  	return isDEWPolicy && reportMetadata?.pendingExpenseAction === CONST.EXPENSE_PENDING_ACTION.APPROVE;

The approve mutation starts the local animation before writing optimistic Onyx data:

• onApproved?.() runs before API.write():

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

  Lines 752 to 754 in 1cd4070

  	onApproved?.();
  	playSound(SOUNDS.SUCCESS);
  	API.write(WRITE_COMMANDS.APPROVE_MONEY_REQUEST, parameters, {optimisticData, successData, failureData});

• Normal policies rely on optimistic stateNum/statusNum to hide approve:

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

  Lines 477 to 504 in 1cd4070

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

• pendingExpenseAction: APPROVE is only set for DEW in this flow:

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

  Lines 533 to 540 in 1cd4070

  	if (isDEWPolicy) {
  	optimisticData.push({
  	onyxMethod: Onyx.METHOD.MERGE,
  	key: `${ONYXKEYS.COLLECTION.REPORT_METADATA}${expenseReport.reportID}`,
  	value: {
  	pendingExpenseAction: CONST.EXPENSE_PENDING_ACTION.APPROVE,
  	},
  	});

This is different from the search approval flow, which already marks every approved report with REPORT_METADATA.pendingExpenseAction = APPROVE and clears it on success/failure:

• Search optimistic pending approve:

  App/src/libs/actions/Search.ts

  Lines 669 to 680 in 1cd4070

  	function approveMoneyRequestOnSearch(hash: number, reportIDList: string[], currentSearchKey?: SearchKey) {
  	const optimisticData: Array<OnyxUpdate<typeof ONYXKEYS.COLLECTION.RAM_ONLY_REPORT_LOADING_STATE | typeof ONYXKEYS.COLLECTION.REPORT_METADATA>> = [
  	{
  	onyxMethod: Onyx.METHOD.MERGE_COLLECTION,
  	key: ONYXKEYS.COLLECTION.RAM_ONLY_REPORT_LOADING_STATE,
  	value: Object.fromEntries(reportIDList.map((reportID) => [`${ONYXKEYS.COLLECTION.RAM_ONLY_REPORT_LOADING_STATE}${reportID}`, {isActionLoading: true}])),
  	},
  	{
  	onyxMethod: Onyx.METHOD.MERGE_COLLECTION,
  	key: ONYXKEYS.COLLECTION.REPORT_METADATA,
  	value: Object.fromEntries(reportIDList.map((reportID) => [`${ONYXKEYS.COLLECTION.REPORT_METADATA}${reportID}`, {pendingExpenseAction: CONST.EXPENSE_PENDING_ACTION.APPROVE}])),
  	},

• Search clear on success/failure:

  App/src/libs/actions/Search.ts

  Lines 689 to 718 in 1cd4070

  	{
  	onyxMethod: Onyx.METHOD.MERGE_COLLECTION,
  	key: ONYXKEYS.COLLECTION.REPORT_METADATA,
  	value: Object.fromEntries(reportIDList.map((reportID) => [`${ONYXKEYS.COLLECTION.REPORT_METADATA}${reportID}`, {pendingExpenseAction: null}])),
  	},
  	];
  	// If we are on the 'Approve', `Unapproved cash` or the `Unapproved company cards` suggested search, remove the report from the view once the action is taken, don't wait for the view to be re-fetched via Search
  	const approveActionSuggestedSearches: Partial<SearchKey[]> = [CONST.SEARCH.SEARCH_KEYS.APPROVE, CONST.SEARCH.SEARCH_KEYS.UNAPPROVED_CASH, CONST.SEARCH.SEARCH_KEYS.UNAPPROVED_CARD];
  	if (approveActionSuggestedSearches.includes(currentSearchKey)) {
  	successData.push({
  	onyxMethod: Onyx.METHOD.MERGE,
  	key: `${ONYXKEYS.COLLECTION.SNAPSHOT}${hash}`,
  	value: {
  	data: Object.fromEntries(reportIDList.map((reportID) => [`${ONYXKEYS.COLLECTION.REPORT}${reportID}`, null])),
  	},
  	});
  	}
  	const failureData: Array<OnyxUpdate<typeof ONYXKEYS.COLLECTION.RAM_ONLY_REPORT_LOADING_STATE | typeof ONYXKEYS.COLLECTION.REPORT_METADATA | typeof ONYXKEYS.COLLECTION.REPORT>> = [
  	{
  	onyxMethod: Onyx.METHOD.MERGE_COLLECTION,
  	key: ONYXKEYS.COLLECTION.RAM_ONLY_REPORT_LOADING_STATE,
  	value: Object.fromEntries(reportIDList.map((reportID) => [`${ONYXKEYS.COLLECTION.RAM_ONLY_REPORT_LOADING_STATE}${reportID}`, {isActionLoading: false}])),
  	},
  	{
  	onyxMethod: Onyx.METHOD.MERGE_COLLECTION,
  	key: ONYXKEYS.COLLECTION.REPORT_METADATA,
  	value: Object.fromEntries(reportIDList.map((reportID) => [`${ONYXKEYS.COLLECTION.REPORT_METADATA}${reportID}`, {pendingExpenseAction: null}])),
  	},

History checked:

• git log -S"pendingExpenseAction: CONST.EXPENSE_PENDING_ACTION.APPROVE" points to PR [NOQA] perf: narrow mount-time work in IOURequestStepAmount #92775, merged June 9, 2026: [NOQA] perf: narrow mount-time work in IOURequestStepAmount #92775
• git blame shows the preview canApprove() / animation action selection lines came from commit 73665ddcb44, while the approve-flow metadata write came from 021f04d8673. The local checkout is grafted/shallow, so full git show --stat is noisy, but targeted line history confirms the current asymmetry.

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

Use the same pending-approve metadata pattern for the single report approval flow, but keep the change scoped so DEW-specific UI does not regress.

1. In approveMoneyRequest(), enqueue the optimistic Onyx update before starting the animation.
2. Set REPORT_METADATA[reportID].pendingExpenseAction = APPROVE for all policies, not only DEW.
3. Clear that metadata in both success and failure data.
4. In ReportPreviewActionUtils.canApprove(), suppress Approve when reportMetadata.pendingExpenseAction === APPROVE. Do not change hasPendingDEWApprove() globally, because other places use it for DEW-specific messages/next-step behavior.

Small diff sketch:

diff --git a/src/libs/ReportPreviewActionUtils.ts b/src/libs/ReportPreviewActionUtils.ts
@@
 function canApprove(report: Report, currentUserAccountID: number, reportMetadata: OnyxEntry<ReportMetadata>, policy?: Policy, transactions?: Transaction[]) {
@@
+    if (reportMetadata?.pendingExpenseAction === CONST.EXPENSE_PENDING_ACTION.APPROVE) {
+        return false;
+    }
+
     const isDEWPolicy = hasDynamicExternalWorkflow(policy);
     if (hasPendingDEWApprove(reportMetadata, isDEWPolicy)) {
         return false;
     }

diff --git a/src/libs/actions/IOU/ReportWorkflow.ts b/src/libs/actions/IOU/ReportWorkflow.ts
@@
-    if (isDEWPolicy) {
-        optimisticData.push({
-            onyxMethod: Onyx.METHOD.MERGE,
-            key: `${ONYXKEYS.COLLECTION.REPORT_METADATA}${expenseReport.reportID}`,
-            value: {
-                pendingExpenseAction: CONST.EXPENSE_PENDING_ACTION.APPROVE,
-            },
-        });
-    }
+    optimisticData.push({
+        onyxMethod: Onyx.METHOD.MERGE,
+        key: `${ONYXKEYS.COLLECTION.REPORT_METADATA}${expenseReport.reportID}`,
+        value: {pendingExpenseAction: CONST.EXPENSE_PENDING_ACTION.APPROVE},
+    });
@@
-    if (isDEWPolicy) {
-        successData.push({
+    successData.push({
             onyxMethod: Onyx.METHOD.MERGE,
             key: `${ONYXKEYS.COLLECTION.REPORT_METADATA}${expenseReport.reportID}`,
-            value: {
-                pendingExpenseAction: null,
-            },
-        });
-    }
+            value: {pendingExpenseAction: null},
+    });
@@
-    onApproved?.();
-    playSound(SOUNDS.SUCCESS);
     API.write(WRITE_COMMANDS.APPROVE_MONEY_REQUEST, parameters, {optimisticData, successData, failureData});
+    onApproved?.();
+    playSound(SOUNDS.SUCCESS);

This should not regress DEW because DEW already uses the same metadata value. It should not regress search because search already sets and clears the same metadata for normal approvals. It is scoped to preview approve eligibility, so existing DEW-only display logic that uses hasPendingDEWApprove() keeps the same behavior.

What alternative solutions did you explore? (Optional)

Only moving onApproved?.() after API.write() reduces the race, but it still leaves the preview dependent on report state updates only.

Changing hasPendingDEWApprove() to ignore the DEW flag would be broader than needed and could affect DEW-specific next-step/system-message logic. A local pending-approve guard in the preview action utility is safer.

[KJ21-ENG]

🚨 Edited by proposal-police: This proposal was edited at 2026-06-09 13:22:15 UTC.

Proposal

What is the root cause of that problem?

The workspace chat preview derives the button from the expense report's current policy and report state, but the preview approval path can submit the approve workflow with a different policy.

In ApproveActionButton and the approve branch of PayActionButton, the component reads the expense report policy, but passes policy: activePolicy into approveMoneyRequest(). The hold-menu submit path does the same. approveMoneyRequest() then uses that policy to decide whether the report is a DEW report and whether to optimistically update stateNum, statusNum, and managerID.

So if the active workspace policy is not the same as the report's policy, especially when the active policy is DEW and the report being approved is a normal workspace report, the approve action takes the DEW optimistic path and does not update the report status/manager. Meanwhile getReportPreviewAction() evaluates the real report policy, sees a normal submitted report that is still assigned to the current approver, and returns APPROVE again as soon as the short approved animation stops. When the backend update finally arrives, the button disappears again.

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

Make approval workflow decisions use the expense report's own policy, not the currently active workspace policy.

Concretely:

• In the report-preview approval callers (ApproveActionButton, the approve branch in PayActionButton, and the held-expense submit path used by the preview), pass the expense report policy as the workflow policy when calling approveMoneyRequest().
• As a defensive cleanup in approveMoneyRequest(), use expenseReportPolicy as the canonical workflow policy for DEW detection, optimistic next-step generation, duplicate checks, and hold approval data. Keep the separate billing restriction check on expenseReportPolicy.
• Do not change payment/KYC paths that legitimately need the active policy for payment setup.
• Preserve actual DEW behavior: DEW reports should still use pendingExpenseAction and wait for backend confirmation; normal reports should optimistically update stateNum, statusNum, and managerID.
• Add regression coverage for approving a normal report while NVP_ACTIVE_POLICY_ID points to a DEW policy, verifying that the normal optimistic report update is still applied and getReportPreviewAction() does not return APPROVE again after the animation flag clears.

I would also mirror the predicted approval state into the parent REPORT_PREVIEW action's childStateNum, childStatusNum, and, when forwarded, childManagerAccountID, matching the pay/reopen/retract patterns. That keeps the preview status display in sync, but the main flicker fix is using the report policy for the approve workflow.

What alternative solutions did you explore? (Optional)

A local "just approved" latch in the preview can hide the flicker, but it only masks the stale action selection. It would still let approveMoneyRequest() build optimistic data from the wrong policy and would need extra failure-clearing logic to avoid hiding a legitimate retry. Fixing the policy source addresses the state mismatch directly.

[melvin-bot]

Current assignee @FitseTLT is eligible for the External assigner, not assigning anyone new.

[melvin-bot]

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

[github-actions]

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

[lorretheboy]

Proposal

What is the root cause of that problem?

The visibility of the Approve button is driven by two independent state sources that are never synchronized, and getReportPreviewAction evaluates them in sequence — the local animation flag first, then the Onyx report status:

App/src/libs/ReportPreviewActionUtils.ts

Lines 224 to 246 in 1f59d37

	// We want to have action displayed for either paid or approved animations
	if (isPaidAnimationRunning || isApprovedAnimationRunning) {
	return CONST.REPORT.REPORT_PREVIEW_ACTIONS.PAY;
	}
	if (isSubmittingAnimationRunning) {
	return CONST.REPORT.REPORT_PREVIEW_ACTIONS.SUBMIT;
	}
	if (isAddExpenseAction(report, transactions ?? [], isReportArchived)) {
	return CONST.REPORT.REPORT_PREVIEW_ACTIONS.ADD_EXPENSE;
	}
	if (isDEWSubmitPending && isOpenReport(report)) {
	return CONST.REPORT.REPORT_PREVIEW_ACTIONS.VIEW;
	}
	if (canSubmit(report, isReportArchived, currentUserAccountID, currentUserLogin, violationsData, policy, transactions)) {
	return CONST.REPORT.REPORT_PREVIEW_ACTIONS.SUBMIT;
	}
	if (canApprove(report, currentUserAccountID, reportMetadata, policy, transactions)) {
	return CONST.REPORT.REPORT_PREVIEW_ACTIONS.APPROVE;
	}

When you tap Approve, approveMoneyRequest fires the animation callback and then writes the optimistic Onyx update:

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

Lines 752 to 754 in 1f59d37

	onApproved?.();
	playSound(SOUNDS.SUCCESS);
	API.write(WRITE_COMMANDS.APPROVE_MONEY_REQUEST, parameters, {optimisticData, successData, failureData});

onApproved sets isApprovedAnimationRunning = true (local React state), while API.write flips the report's stateNum/statusNum to approved/submitted in Onyx — a broadcast that propagates in a later render than the local setState. So the suppression of the button bounces between two sources:

• while isApprovedAnimationRunning is true → returns PAY (the animated button), so Approve is hidden;
• once canApprove sees the approved report → returns VIEW, so Approve is hidden.

The animation flag is reset on a fixed animation timer, independent of Onyx, when the settlement animation finishes:

App/src/components/SettlementButton/AnimatedSettlementButton.tsx

Lines 53 to 59 in 1f59d37

	const finishAnimationAndReset = () => {
	setMinWidth(0);
	setCanShow(true);
	height.set(variables.componentSizeNormal);
	buttonMarginTop.set(shouldAddTopMargin ? gap : 0);
	onAnimationFinish();
	};

App/src/hooks/usePaymentAnimations.ts

Lines 9 to 13 in 1f59d37

	const stopAnimation = useCallback(() => {
	setIsPaidAnimationRunning(false);
	setIsApprovedAnimationRunning(false);
	setIsSubmittingAnimationRunning(false);
	}, []);

If that timer-driven reset lands in a render where the optimistic status hasn't yet propagated (or is momentarily overwritten by successData), canApprove is still true → the Approve button reappears, then disappears again once Onyx settles. This is a race, hence "not consistently reproducible." On a DEW policy it can't reproduce because approveMoneyRequest skips the stateNum update and instead sets reportMetadata.pendingExpenseAction, which makes canApprove short-circuit deterministically via hasPendingDEWApprove — there is no racing second source.

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

Make the button suppression come from a single source of truth so there is no window where canApprove is re-evaluated as true. Tie the lifetime of isApprovedAnimationRunning to the Onyx report state instead of the fixed animation timer: keep it true until the report is actually observed as approved/submitted, so by the time the flag clears, canApprove already returns false.

Concretely, onAnimationFinish should not unconditionally reset the flag here:

App/src/components/SettlementButton/AnimatedSettlementButton.tsx

Lines 53 to 59 in 1f59d37

	const finishAnimationAndReset = () => {
	setMinWidth(0);
	setCanShow(true);
	height.set(variables.componentSizeNormal);
	buttonMarginTop.set(shouldAddTopMargin ? gap : 0);
	onAnimationFinish();
	};

Instead defer stopAnimation until the optimistic approval has propagated (e.g. gate the reset on isReportApproved/!isProcessingReport for the report), so the animation flag and the Onyx status hand off cleanly with no overlap gap.

What alternative solutions did you explore? (Optional)

Mirror the DEW path for normal workspaces: have canApprove also return false while an optimistic approve is pending (a pending flag on the report/metadata, the same mechanism that already makes DEW immune):

App/src/libs/ReportPreviewActionUtils.ts

Lines 80 to 92 in 1f59d37

	const isDEWPolicy = hasDynamicExternalWorkflow(policy);
	if (hasPendingDEWApprove(reportMetadata, isDEWPolicy)) {
	return false;
	}
	const isPreventSelfApprovalEnabled = policy?.preventSelfApproval;
	const isReportSubmitter = isCurrentUserSubmitter(report);
	if (isPreventSelfApprovalEnabled && isReportSubmitter) {
	return false;
	}
	return isExpense && isProcessing && !!isApprovalEnabled && reportTransactions.length > 0 && isCurrentUserManager;

This removes the dependency on stateNum propagation timing entirely, at the cost of touching the optimistic data in approveMoneyRequest.

---

Proposed change (for review): main...lorretheboy:App:proposal-93067

[mukhrr]

updated proposal. RCA and solution remained unchanged