[Due for payment 2026-03-30] [$250] Submitted/approved/paid animation runs even when actions are restricted

[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: 9.3.24-1
Reproducible in staging?: Y
Reproducible in production?: Y
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: @bernhardoj
Slack conversation (hyperlinked to channel name): #Expensify Bugs

Action Performed:

1. Log in to an account that has reports pending submit/approve/pay and has restricted billing actions.
2. Attempt to submit, approve, or pay one of these reports.

Expected Result:

The submitted/approved/paid animation should not run if the action is restricted and does not complete.

Actual Result:

The submitted/approved/paid animation runs even though the action is restricted and does not complete.

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

web.mp4

Recording.2418.mp4

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @mallenexpensify

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022025624249921889086
• Upwork Job ID: 2025624249921889086
• Last Price Increase: 2026-02-22

[melvin-bot]

Triggered auto assignment to @jliexpensify (Bug), see https://stackoverflow.com/c/expensify/questions/14418 for more details. Please add this bug to a GH project, as outlined in the SO.

[MelvinBot]

Proposal

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

When a user with restricted billing actions attempts to submit, approve, or pay a report, the success animation (e.g., "Submitted", "Approved", "Payment complete") plays even though the action is blocked and does not complete. The user sees a misleading success animation before being redirected to the restricted action page.

What is the root cause of that problem?

The animation is started before the billing restriction check runs. In the button click handlers in MoneyReportHeader.tsx and MoneyRequestReportPreviewContent.tsx, the pattern is:

1. startSubmittingAnimation() / startApprovedAnimation() / startAnimation() is called first
2. Then the IOU action function (submitReport / approveMoneyRequest / payMoneyRequest) is called

The shouldRestrictUserBillableActions() check lives inside those IOU action functions (at IOU/index.ts:11420 for submit, IOU/index.ts:10536 for approve, IOU/index.ts:11935 for pay). When restricted, these functions navigate to the restricted action page and return early — but the animation is already running and has no mechanism to be cancelled.

The animation state is purely local React state in usePaymentAnimations.ts — stopAnimation is only called via onAnimationFinish, never in response to action failure or restriction.

Affected call sites:

Action	Animation Start	Billing Check (too late)
Submit	MoneyReportHeader.tsx:1052	IOU/index.ts:11420
Approve (onApprove)	MoneyReportHeader.tsx:1026	IOU/index.ts:10536
Approve (confirmApproval)	MoneyReportHeader.tsx:676	IOU/index.ts:10536
Pay (confirmPayment)	MoneyReportHeader.tsx:590/607	IOU/index.ts:11935
Submit (preview)	MoneyRequestReportPreviewContent.tsx:630	IOU/index.ts:11420
Approve (preview)	MoneyRequestReportPreviewContent.tsx:651	IOU/index.ts:10536
Pay (preview)	MoneyRequestReportPreviewContent.tsx:258	IOU/index.ts:11935

Note: The PAY flow via SettlementButton has a correct pre-check in checkForNecessaryAction() that checks shouldRestrictUserBillableActions before confirmPayment is called — so the PAY animation may already be partially guarded depending on the UI path.

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

Add a shouldRestrictUserBillableActions check before the animation starts in each affected button handler. This is a synchronous check (reads from Onyx data in memory), so it can safely run before the animation. The pattern already exists in SettlementButton.checkForNecessaryAction() and should be replicated at each affected call site.

Specifically, in each of the button click handlers listed above, add a check like:

if (policy && shouldRestrictUserBillableActions(policy.id)) {
    Navigation.navigate(ROUTES.RESTRICTED_ACTION.getRoute(policy.id));
    return;
}

before calling startSubmittingAnimation() / startApprovedAnimation() / startAnimation().

This needs to be done in both MoneyReportHeader.tsx (submit onPress, onApprove, confirmApproval, confirmPayment) and MoneyRequestReportPreviewContent.tsx (submit onPress, approve onApprove, confirmPayment).

What alternative solutions did you explore? (Optional)

1. Have IOU actions return a result and cancel animation on failure: The action functions could return a boolean/promise indicating whether the action proceeded, and the caller could stop the animation. However, this is more invasive and doesn't match the existing optimistic pattern.

2. Listen to Onyx failure data to cancel animation: Connect the animation state to Onyx so it auto-reverts on failure. This would be over-engineered — the billing restriction is a synchronous, client-side check that should simply run before the animation.

The recommended approach (pre-check before animation) is the simplest, matches the existing pattern in SettlementButton, and addresses the root cause directly.

---

Next Steps for Contributor+ team: Reply with @MelvinBot implement this to create a draft PR, or @MelvinBot <your feedback> to refine this analysis.

[melvin-bot]

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

[melvin-bot]

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

[nkdengineer]

Proposal

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

The submitted/approved/paid animation runs even though the action is restricted and does not complete.

What is the root cause of that problem?

The logic navigate to the restricted page is in submitReport, but we always start the button animation without checking the policy is restricted or not

App/src/components/ReportActionItem/MoneyRequestReportPreview/MoneyRequestReportPreviewContent.tsx

Lines 630 to 631 in 97b8ca7

	startSubmittingAnimation();
	submitReport(iouReport, policy, currentUserAccountID, currentUserEmail, hasViolations, isASAPSubmitBetaEnabled, iouReportNextStep);

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

Lines 11417 to 11430 in 97b8ca7

	if (!expenseReport) {
	return;
	}
	if (expenseReport.policyID && shouldRestrictUserBillableActions(expenseReport.policyID)) {
	Navigation.navigate(ROUTES.RESTRICTED_ACTION.getRoute(expenseReport.policyID));
	return;
	}
	const parentReport = getReportOrDraftReport(expenseReport.parentReportID);
	const isCurrentUserManager = currentUserAccountIDParam === expenseReport.managerID;
	const isSubmitAndClosePolicy = isSubmitAndClose(policy);
	const adminAccountID = policy?.role === CONST.POLICY.ROLE.ADMIN ? currentUserAccountIDParam : undefined;
	const optimisticSubmittedReportAction = buildOptimisticSubmittedReportAction(
	expenseReport?.total ?? 0,

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

We should add onSubmitted callback param to submitReport and only call onSubmitted callback after this check

Then we can pass startSubmittingAnimation as onSubmitted callback param.

App/src/components/ReportActionItem/MoneyRequestReportPreview/MoneyRequestReportPreviewContent.tsx

Lines 630 to 631 in 97b8ca7

	startSubmittingAnimation();
	submitReport(iouReport, policy, currentUserAccountID, currentUserEmail, hasViolations, isASAPSubmitBetaEnabled, iouReportNextStep);

We should fix the same for the approve/paid action and fix the same problem for primary action.

What alternative solutions did you explore? (Optional)

We can add the check shouldRestrictUserBillableActions when calling startSubmittingAnimation

App/src/components/ReportActionItem/MoneyRequestReportPreview/MoneyRequestReportPreviewContent.tsx

Lines 630 to 631 in 97b8ca7

	startSubmittingAnimation();
	submitReport(iouReport, policy, currentUserAccountID, currentUserEmail, hasViolations, isASAPSubmitBetaEnabled, iouReportNextStep);

Reminder: Please use plain English, be brief and avoid jargon. Feel free to use images, charts or pseudo-code if necessary. Do not post large multi-line diffs or write walls of text. Do not create PRs unless you have been hired for this job.

[annaweber830]

Proposal

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

When a user is in a policy/workspace where billable actions are restricted, attempting to submit, approve, or pay a report is blocked and redirects them to the restricted-action flow. However, the UI still plays the success animation (Submitted/Approved/Paid), which incorrectly implies the action succeeded.

What is the root cause of that problem?

Some UI handlers start the success animation before calling the IOU action.

App/src/components/MoneyReportHeader.tsx

Lines 1044 to 1054 in 97b8ca7

	onPress={() => {
	if (!moneyRequestReport || shouldBlockSubmit) {
	return;
	}
	if (hasDynamicExternalWorkflow(policy) && !isDEWBetaEnabled) {
	showDWEModal();
	return;
	}
	startSubmittingAnimation();
	submitReport(moneyRequestReport, policy, accountID, email ?? '', hasViolations, isASAPSubmitBetaEnabled, nextStep);
	if (currentSearchQueryJSON && !isOffline) {

onPress={() => {
    if (!moneyRequestReport || shouldBlockSubmit) {
        return;
    }
    if (hasDynamicExternalWorkflow(policy) && !isDEWBetaEnabled) {
        showDWEModal();
        return;
    }
    startSubmittingAnimation();
    submitReport(moneyRequestReport, policy, accountID, email ?? '', hasViolations, isASAPSubmitBetaEnabled, nextStep);
}}

But the billing restriction guard lives inside the IOU actions, and when it triggers it navigates away and returns early.

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

Lines 11417 to 11423 in 97b8ca7

	if (!expenseReport) {
	return;
	}
	if (expenseReport.policyID && shouldRestrictUserBillableActions(expenseReport.policyID)) {
	Navigation.navigate(ROUTES.RESTRICTED_ACTION.getRoute(expenseReport.policyID));
	return;
	}

if (expenseReport.policyID && shouldRestrictUserBillableActions(expenseReport.policyID)) {
    Navigation.navigate(ROUTES.RESTRICTED_ACTION.getRoute(expenseReport.policyID));
    return;
}

So, for restricted users, the handler starts the animation, then submitReport() immediately navigates to ROUTES.RESTRICTED_ACTION and returns without submitting/approving/paying — leaving the already-started “success” animation visible even though the action did not complete.

The same “animation-first, restriction-check-later” pattern exists for approve and pay handlers too (e.g. startApprovedAnimation() before approveMoneyRequest(), and startAnimation() before payMoneyRequest()).

For example, the pay handler starts the paid animation before calling payMoneyRequest():

App/src/components/MoneyReportHeader.tsx

Lines 607 to 618 in 97b8ca7

	startAnimation();
	payMoneyRequest({
	paymentType: type,
	chatReport,
	iouReport: moneyRequestReport,
	introSelected,
	iouReportCurrentNextStepDeprecated: nextStep,
	currentUserAccountID: accountID,
	activePolicy,
	policy,
	betas,
	});

startAnimation();
payMoneyRequest({
    paymentType: type,
    chatReport,
    iouReport: moneyRequestReport,
    introSelected,
    iouReportCurrentNextStepDeprecated: nextStep,
    currentUserAccountID: accountID,
    activePolicy,
    policy,
    betas,
});

But payMoneyRequest() has the restriction guard and returns immediately (after navigating) when restricted:

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

Lines 11933 to 11938 in 97b8ca7

	function payMoneyRequest(params: PayMoneyRequestFunctionParams) {
	const {paymentType, chatReport, iouReport, introSelected, iouReportCurrentNextStepDeprecated, currentUserAccountID, paymentPolicyID, full = true, activePolicy, policy, betas} = params;
	if (chatReport.policyID && shouldRestrictUserBillableActions(chatReport.policyID)) {
	Navigation.navigate(ROUTES.RESTRICTED_ACTION.getRoute(chatReport.policyID));
	return;
	}

if (chatReport.policyID && shouldRestrictUserBillableActions(chatReport.policyID)) {
    Navigation.navigate(ROUTES.RESTRICTED_ACTION.getRoute(chatReport.policyID));
    return;
}

This also applies to approving a report. The UI starts the approved animation first:

App/src/components/MoneyReportHeader.tsx

Lines 1021 to 1028 in 97b8ca7

	const onApprove = (isFullApproval: boolean) => {
	if (hasDynamicExternalWorkflow(policy) && !isDEWBetaEnabled) {
	showDWEModal();
	return;
	}
	startApprovedAnimation();
	approveMoneyRequest(moneyRequestReport, policy, accountID, email ?? '', hasViolations, isASAPSubmitBetaEnabled, nextStep, betas, isFullApproval);
	if (currentSearchQueryJSON) {

const onApprove = (isFullApproval: boolean) => {
    if (hasDynamicExternalWorkflow(policy) && !isDEWBetaEnabled) {
        showDWEModal();
        return;
    }
    startApprovedAnimation();
    approveMoneyRequest(moneyRequestReport, policy, accountID, email ?? '', hasViolations, isASAPSubmitBetaEnabled, nextStep, betas, isFullApproval);
    if (currentSearchQueryJSON) {
        search({
            searchKey: currentSearchKey,
            shouldCalculateTotals: true,
            offset: 0,
            queryJSON: currentSearchQueryJSON,
            isLoading: !!currentSearchResults?.search?.isLoading,
        });
    }
};

And the action has the restriction guard and returns early (same navigation+return behavior as submit/pay):

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

Lines 10532 to 10539 in 97b8ca7

	if (!expenseReport) {
	return;
	}
	if (expenseReport.policyID && shouldRestrictUserBillableActions(expenseReport.policyID)) {
	Navigation.navigate(ROUTES.RESTRICTED_ACTION.getRoute(expenseReport.policyID));
	return;
	}

if (expenseReport.policyID && shouldRestrictUserBillableActions(expenseReport.policyID)) {
    Navigation.navigate(ROUTES.RESTRICTED_ACTION.getRoute(expenseReport.policyID));
    return;
}

Once the animation starts, it’s just local React state from usePaymentAnimations() and nothing in the restriction-navigation path stops it (it only stops when the animation finishes and the component calls stopAnimation).

App/src/hooks/usePaymentAnimations.ts

Lines 4 to 38 in 97b8ca7

	function usePaymentAnimations() {
	const [isPaidAnimationRunning, setIsPaidAnimationRunning] = useState(false);
	const [isApprovedAnimationRunning, setIsApprovedAnimationRunning] = useState(false);
	const [isSubmittingAnimationRunning, setIsSubmittingAnimationRunning] = useState(false);
	const stopAnimation = useCallback(() => {
	setIsPaidAnimationRunning(false);
	setIsApprovedAnimationRunning(false);
	setIsSubmittingAnimationRunning(false);
	}, []);
	const startAnimation = useCallback(() => {
	setIsPaidAnimationRunning(true);
	HapticFeedback.longPress();
	}, []);
	const startApprovedAnimation = useCallback(() => {
	setIsApprovedAnimationRunning(true);
	HapticFeedback.longPress();
	}, []);
	const startSubmittingAnimation = useCallback(() => {
	setIsSubmittingAnimationRunning(true);
	HapticFeedback.longPress();
	}, []);
	return {
	isPaidAnimationRunning,
	isApprovedAnimationRunning,
	isSubmittingAnimationRunning,
	stopAnimation,
	startAnimation,
	startApprovedAnimation,
	startSubmittingAnimation,
	};

const startAnimation = useCallback(() => {
    setIsPaidAnimationRunning(true);
    HapticFeedback.longPress();
}, []);

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

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

We should perform the same shouldRestrictUserBillableActions() check in the UI handler before starting the animation, and navigate/return early if restricted. This matches the existing pattern used by the pay flow’s SettlementButton.checkForNecessaryAction().

App/src/components/SettlementButton/index.tsx

Lines 198 to 220 in 97b8ca7

	const checkForNecessaryAction = useCallback(() => {
	if (isDelegateAccessRestricted) {
	showDelegateNoAccessModal();
	return true;
	}
	if (isAccountLocked) {
	showLockedAccountModal();
	return true;
	}
	if (!isUserValidated) {
	handleUnvalidatedUserNavigation(chatReportID, reportID);
	return true;
	}
	if (policy && shouldRestrictUserBillableActions(policy.id)) {
	Navigation.navigate(ROUTES.RESTRICTED_ACTION.getRoute(policy.id));
	return true;
	}
	return false;
	}, [policy, isAccountLocked, isUserValidated, chatReportID, reportID, showLockedAccountModal, isDelegateAccessRestricted, showDelegateNoAccessModal]);

For example, update the submit primary action handler in MoneyReportHeader like this.

App/src/components/MoneyReportHeader.tsx

Lines 1044 to 1064 in 97b8ca7

	onPress={() => {
	if (!moneyRequestReport || shouldBlockSubmit) {
	return;
	}
	if (hasDynamicExternalWorkflow(policy) && !isDEWBetaEnabled) {
	showDWEModal();
	return;
	}
	startSubmittingAnimation();
	submitReport(moneyRequestReport, policy, accountID, email ?? '', hasViolations, isASAPSubmitBetaEnabled, nextStep);
	if (currentSearchQueryJSON && !isOffline) {
	search({
	searchKey: currentSearchKey,
	shouldCalculateTotals,
	offset: 0,
	queryJSON: currentSearchQueryJSON,
	isOffline,
	isLoading: !!currentSearchResults?.search?.isLoading,
	});
	}
	}}

Current code:

onPress={() => {
    if (!moneyRequestReport || shouldBlockSubmit) {
        return;
    }
    if (hasDynamicExternalWorkflow(policy) && !isDEWBetaEnabled) {
        showDWEModal();
        return;
    }
    startSubmittingAnimation();
    submitReport(moneyRequestReport, policy, accountID, email ?? '', hasViolations, isASAPSubmitBetaEnabled, nextStep);
    if (currentSearchQueryJSON && !isOffline) {
        search({
            searchKey: currentSearchKey,
            shouldCalculateTotals,
            offset: 0,
            queryJSON: currentSearchQueryJSON,
            isOffline,
            isLoading: !!currentSearchResults?.search?.isLoading,
        });
    }
}}

Updated code:

onPress={() => {
    if (!moneyRequestReport || shouldBlockSubmit) {
        return;
    }
    if (hasDynamicExternalWorkflow(policy) && !isDEWBetaEnabled) {
        showDWEModal();
        return;
    }

    const policyID = moneyRequestReport.policyID;
    if (policyID && shouldRestrictUserBillableActions(policyID, userBillingGraceEndPeriodCollection)) {
        Navigation.navigate(ROUTES.RESTRICTED_ACTION.getRoute(policyID));
        return;
    }

    startSubmittingAnimation();
    submitReport(moneyRequestReport, policy, accountID, email ?? '', hasViolations, isASAPSubmitBetaEnabled, nextStep);
    if (currentSearchQueryJSON && !isOffline) {
        search({
            searchKey: currentSearchKey,
            shouldCalculateTotals,
            offset: 0,
            queryJSON: currentSearchQueryJSON,
            isOffline,
            isLoading: !!currentSearchResults?.search?.isLoading,
        });
    }
}}

Then apply the same pre-check pattern to the other affected handlers before they call startSubmittingAnimation(), startApprovedAnimation(), or startAnimation():

• src/components/MoneyReportHeader.tsx (onApprove, confirmApproval, confirmPayment)
• src/components/ReportActionItem/MoneyRequestReportPreview/MoneyRequestReportPreviewContent.tsx (submit/approve/pay preview actions)

This ensures we only show “success” animations when the action is allowed to proceed.

What alternative solutions did you explore? (Optional)

• Existing proposals on this issue already point toward “add a pre-check before the animation” (or add callbacks to delay starting animations), but they don’t include the required current/updated code blocks and concrete change points across both header + preview handlers.
• Another option is to refactor IOU actions to return a boolean/throw so callers can start/cancel animations based on the result. That’s more invasive and works against the app’s optimistic/action-driven patterns; the restriction guard is synchronous and can be handled cleanly at the UI trigger points.

[rafaelafonso]

Proposal

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

When a user with restricted billing actions (e.g., pending billing dispute) attempts to submit, approve, or pay an expense report, the success animation (submitted/approved/paid Lottie animation) plays optimistically even though the action is restricted and does not actually complete. The animation should not run if the action is going to be blocked.

What is the root cause of that problem?

The submit/approve/pay actions in src/libs/actions/IOU (e.g., submitReport, approveMoneyRequest, payMoneyRequest) follow Expensify's standard optimistic update pattern: they immediately set optimistic data (updating the report's statusNum and stateNum to the next state) before making the API call. The UI components that render the report status detect this optimistic status change and trigger the corresponding Lottie animation.

However, the billing restriction check that determines whether the action should be allowed is handled separately from the optimistic update flow. The button handler in the report header/preview component (likely in src/components/MoneyReportHeader.tsx or src/components/ReportPreview.tsx) calls the action function, which optimistically updates the report status and triggers the animation. When the API call then fails due to restricted billing, the failure data rolls back the status — but the animation has already played.

The core issue is that there is no pre-flight check for billing restrictions before the optimistic update is applied. The animation is a visual consequence of the optimistic status change, so if the optimistic update fires, the animation will always fire — even if the action is doomed to fail.

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

The fix should add a billing restriction check before the optimistic update and animation are triggered, at the call site where the submit/approve/pay button handler invokes the action.

Specifically:

1. In the button handler (in MoneyReportHeader.tsx or ReportPreview.tsx, or wherever the submit/approve/pay CTA is wired up), add a check using the existing billing restriction utilities (e.g., SubscriptionUtils functions that check for billing disputes or restricted actions, such as hasBillingDisputePending() or similar) before calling submitReport/approveMoneyRequest/payMoneyRequest.

2. If billing actions are restricted, the handler should show the appropriate error modal or banner (the billing dispute modal that already exists in the codebase) and return early without calling the action function. This prevents the optimistic data from being set, which in turn prevents the animation from triggering.

3. This is the same pattern used elsewhere in the app when actions need to be gated by a pre-condition: check the condition first, show a modal/error if it fails, and only proceed to the optimistic action if the check passes.

The key principle is: move the restriction check upstream of the optimistic update, rather than relying on the API failure rollback to undo the visual effects. The animation is a one-shot visual that cannot be "rolled back," unlike data changes — so it must be prevented, not reverted.

What alternative solutions did you explore? (Optional)

1. Suppressing the animation on failure rollback: When the API returns a billing restriction error and failure data restores the previous status, we could try to cancel the animation. However, Lottie animations are fire-and-forget — once started, they play to completion. Trying to cancel or reverse them mid-flight would create jarring UX (a half-played confetti that suddenly disappears). Prevention is better than cancellation.

2. Adding the billing check inside the action functions (submitReport, approveMoneyRequest, etc.) and returning early before setting optimistic data: This would work functionally but pollutes the action layer with UI-gating logic. The action functions should be responsible for data operations, not for deciding whether to show billing modals. The component layer is the right place for this gate.

3. Making the animation conditional on the API response rather than the optimistic update: This would mean the animation only plays after the server confirms success. While technically correct, it would add a noticeable delay (network round-trip) to the animation for all users, degrading the UX for the vast majority who don't have billing restrictions. The optimistic pattern is intentional — the fix should preserve it for normal cases and only skip it for restricted cases.

What results did you see from your testing?

1. Log in with an account that has restricted billing actions → Submit a report → Animation should NOT play, billing restriction modal should appear
2. Same test for Approve → Animation should NOT play
3. Same test for Pay → Animation should NOT play
4. Log in with a normal account (no billing restrictions) → Submit/Approve/Pay → Animation SHOULD play as before (no regression)
5. Test the billing restriction modal still appears correctly and allows the user to resolve the issue
6. Test offline: if billing restriction data is not yet loaded, the optimistic action should still proceed normally (graceful degradation)