[$250] Blocked Report Submission Briefly Shows “Submitted” State Before Reverting

[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.69-0
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: @MitchExpensify
Slack conversation (hyperlinked to channel name): #Quality

Action Performed:

1. Create a report that is not eligible for submission (DEW enabled)
2. Click Submit
3. Observe the report state immediately after submission attempt

Expected Result:

When user clicks Submit:
Submit button should show a loading spinner while the DEW workflow is calculated
Report state should not temporarily change to “Submitted”
Next steps/status should remain unchanged if submission is blocked

Actual Result:

Report briefly appears as:
“Submitted”
UI later reverts after workflow validation blocks submission

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

Recording.2842.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022052826804202633324
• Upwork Job ID: 2052826804202633324
• Last Price Increase: 2026-05-08

Issue Owner

Current Issue Owner: @brunovjk

[MelvinBot]

Proposal

What is the root cause of that problem?

When a user clicks Submit on a DEW (Dynamic External Workflow) policy report, submitReport calls onSubmitted?.() unconditionally — before API.write() and regardless of whether the policy uses DEW. This triggers startSubmittingAnimation which causes the AnimatedSubmitButton to show a loading spinner for 1 second, then display "Submitted" text for 1.5 seconds — even though the DEW workflow hasn't resolved yet.

The rest of the DEW optimistic handling is correct: stateNum/statusNum are not optimistically set to SUBMITTED for DEW policies, and no optimistic SUBMITTED report action is added when online. The problem is isolated to the button animation firing unconditionally.

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

For DEW policies (when online), onSubmitted should not be called, or the animation behavior should be adjusted to not show the "Submitted" state. The simplest fix is to skip calling onSubmitted?.() at ReportWorkflow.ts:1510 when isDEWPolicy && !getIsOffline(). This way:

• DEW online: No "Submitted" animation plays. The pendingExpenseAction metadata flag already handles showing the pending state, and hasPendingDEWSubmit hides the submit button while the server evaluates the workflow.
• DEW offline: Animation still plays (acceptable since the optimistic SUBMITTED action is also added when offline).
• Non-DEW: No change to current behavior.

What alternative solutions did you explore? (Optional)

An alternative would be to modify AnimatedSubmitButton to accept a prop that keeps it in the loading/spinner state indefinitely (without transitioning to "Submitted" text) and let the DEW server response resolve the animation. However, this adds more complexity than the simpler guard in submitReport.

Investigation details

Animation flow:

1. User clicks Submit → onPress → submitReport() (SubmitActionButton.tsx:76-91)
2. submitReport calls onSubmitted?.() at line 1510 — unconditionally
3. onSubmitted = startSubmittingAnimation → sets isSubmittingAnimationRunning = true
4. AnimatedSubmitButton shows loading for ANIMATION_SUBMIT_LOADING_STATE_DURATION (1000ms), then "Submitted" text for ANIMATION_SUBMIT_SUBMITTED_STATE_VISIBLE_DURATION (1500ms) (CONST/index.ts:272-273)

DEW optimistic data (correctly guarded):

• stateNum/statusNum NOT set to SUBMITTED for DEW (line 1330-1342)
• No optimistic SUBMITTED report action when online (line 1274)
• nextStep set to null for DEW (lines 1277-1300)
• pendingExpenseAction set on metadata instead (lines 1387-1395)

Related issue: #89933 (crash after tapping back from DEW submit failure) is related — both stem from DEW submit edge cases.

---

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.

[melvin-bot]

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

[wildan-m]

🚫 Duplicated proposal withdrawn by 🤖 ProposalPolice.

[MobileMage]

🚫 Duplicated proposal withdrawn by 🤖 ProposalPolice.

[melvin-bot]

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

[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.

[github-actions]

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

[dilshodmackbook-sketch]

Proposal

What is the root cause of that problem?

When the Submit button is pressed, the parent screen calls startSubmittingAnimation via the onSubmitted callback, and submitReport invokes that callback before firing the API call:

https://github.com/Expensify/App/blob/main/src/libs/actions/IOU/ReportWorkflow.ts#L1505-L1512

The button is rendered by AnimatedSubmitButton, which runs a fixed 2-stage animation: it first shows a loading spinner with the "Submit" text, then unconditionally swaps the label to common.submitted for a configured duration before fading out:

https://github.com/Expensify/App/blob/main/src/components/AnimatedSubmitButton/index.tsx#L114-L130

For non-DEW policies this is fine — the report's statusNum is also optimistically flipped to SUBMITTED, so the UI ends in a consistent state. But for DEW policies, submitReport intentionally skips the optimistic state/status update because the backend decides the workflow:

https://github.com/Expensify/App/blob/main/src/libs/actions/IOU/ReportWorkflow.ts#L1271-L1274

https://github.com/Expensify/App/blob/main/src/libs/actions/IOU/ReportWorkflow.ts#L1332-L1344

So when DEW blocks the submission, the animation still walks through "Submit → loading → Submitted → fade out", and once the animation finishes the original "Submit" button reappears (because the report never actually moved to SUBMITTED). That's the brief "Submitted" flash the reporter is seeing.

The two callsites that wire this up are:

https://github.com/Expensify/App/blob/main/src/components/MoneyReportHeaderPrimaryAction/SubmitPrimaryAction.tsx#L74-L104

https://github.com/Expensify/App/blob/main/src/components/ReportActionItem/MoneyRequestReportPreview/SubmitActionButton.tsx#L75-L92

We already have a signal that tells us the DEW workflow is in progress — reportMetadata.pendingExpenseAction === EXPENSE_PENDING_ACTION.SUBMIT, set in submitReport and cleared in both successData and failureData (https://github.com/Expensify/App/blob/main/src/libs/actions/IOU/ReportWorkflow.ts#L1389-L1397). The button just isn't using it.

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

For DEW policies, I think we should skip the "submitted" success animation and instead drive the button from pendingExpenseAction so it stays in a pure loading state until the backend resolves the submission (success or DEW_SUBMIT_FAILED).

1. Don't fire the success animation when DEW is in play — in SubmitPrimaryAction.tsx (and the same change in SubmitActionButton.tsx):

+ const [reportMetadata] = useOnyx(`${ONYXKEYS.COLLECTION.REPORT_METADATA}${reportID}`);
+ const isDEWPolicy = hasDynamicExternalWorkflow(policy);
+ const isPendingDEWSubmit = hasPendingDEWSubmit(reportMetadata, isDEWPolicy);

  submitReport({
      expenseReport: moneyRequestReport,
      policy,
      ...
-     onSubmitted: startSubmittingAnimation,
+     // For DEW, the backend decides the outcome — don't play the "Submitted" success animation.
+     onSubmitted: isDEWPolicy ? undefined : startSubmittingAnimation,
      ownerBillingGracePeriodEnd,
      delegateEmail,
  });

2. Show a real loading state while DEW validates — pass an isLoading prop through to AnimatedSubmitButton and render a loading Button when set, instead of going through the keyframe animation:

- <AnimatedSubmitButton
-     success
-     text={translate('common.submit')}
-     onPress={handleSubmit}
-     isSubmittingAnimationRunning={isSubmittingAnimationRunning}
-     onAnimationFinish={stopAnimation}
-     isDisabled={shouldBlockSubmit}
- />
+ <AnimatedSubmitButton
+     success
+     text={translate('common.submit')}
+     onPress={handleSubmit}
+     isSubmittingAnimationRunning={isSubmittingAnimationRunning}
+     onAnimationFinish={stopAnimation}
+     isDisabled={shouldBlockSubmit || isPendingDEWSubmit}
+     isLoading={isPendingDEWSubmit}
+ />

Inside AnimatedSubmitButton, when isLoading is true and isSubmittingAnimationRunning is false, render a plain <Button isLoading success disabled /> with the "Submit" text — no Keyframe, no common.submitted swap. This way the button visibly shows progress during DEW validation and never displays a misleading "Submitted" label. When the failure data clears pendingExpenseAction, the button returns to its normal state; when the backend instead succeeds, the regular Pusher/server update will move the report past the SUBMIT primary action naturally.

The same two-line wiring change applies to SubmitActionButton.tsx (the report preview variant).

What alternative solutions did you explore?

• Wait for pendingExpenseAction to clear before starting the animation in submitReport: I rejected this because the animation is purely a UX confirmation and triggering it from a backend response would either require subscribing to Onyx inside the action layer or coupling animation timing to network latency, which would feel sluggish for non-DEW flows.
• Always run the optimistic state flip and rely on failureData to revert it: this is what previously caused the bug; the team already deliberately removed the optimistic statusNum/stateNum write for DEW (see the comments at lines 1332 and 1353 of ReportWorkflow.ts). Re-introducing it would reverse that decision.
• Hide the Submit button entirely while pendingExpenseAction === SUBMIT: technically simpler, but it leaves the user with no visual feedback that anything is happening, which contradicts the reporter's expected behavior ("display a loading spinner during DEW workflow calculation").