Report turns to skeleton loading after submitting Per diem expense to Submit workspace

[applause-bot]

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.4.34-12
Reproducible in staging?: Yes
Reproducible in production?: N/A - new feature, doesn't exist in prod
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #94319
Email or phone of affected tester (no customers): applausetester+sdoisdddndos@applause.expensifail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Mac 26.5 / Chrome
App Component: Money Requests

Action Performed:

Precondition:

• Log in with Expensifail account.
• Account has a Control workspace with per diem rates.

1. Go to staging.new.expensify.com
2. Go to self DM.
3. Create a per diem expense.
4. Delete the workspace (delete all workspaces if there are other workspaces).
5. Go back to self DM.
6. Click Submit to my employer.
7. Click Create expense.

Expected Result:

User should be prevented from submitting per diem expense to Submit workspace because Per diem is a Control plan feature.

Actual Result:

After clicking Create expense, report turns to infinite loading. Several reports with RBR appear on LHN.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7209309_1784143981875.16.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Julia Ponikarchuk
Bug ID: 7209309

[applause-bot]

While Applause doesn't embed attachments for this bug, here are the links for quick view:
https://platform.applause.com/services/links/v1/external/deb8d02cab83755a4e9e177fca5b8f2bc347f42f3f55387464157073893e7094

[melvin-bot]

You have been assigned to this deploy blocker because you recently merged this PR: #94319

[melvin-bot]

💬 A slack conversation has been started in #expensify-open-source

[github-actions]

👋 Friendly reminder that deploy blockers are time-sensitive ⏱ issues! Check out the open `StagingDeployCash` deploy checklist to see the list of PRs included in this release, then work quickly to do one of the following:

1. Identify the pull request that introduced this issue and revert it.
2. Find someone who can quickly fix the issue.
3. Fix the issue yourself.

[MelvinBot]

Proposal

What is the root cause of that problem?

The new "Submit to my employer" flow from PR #94319 lets a user create a Submit-plan workspace and move an expense into it, but per diem is a Control‑plan-only feature — and nothing in the confirmation/submission path stops a per diem expense from being submitted to a Submit workspace.

Two gaps combine to produce the stuck skeleton + RBR:

1. No validation guard. The confirmation validator only checks the transaction's own subrate length and amount — it never checks whether the destination policy actually supports per diem. Those checks still pass because the transaction still carries valid subrates from the now-deleted Control workspace. See useConfirmationValidation.ts:280-300. The only existing per‑diem/policy guard is a workspace‑picker filter (OptionsListUtils/index.ts:2339-2342), which this self‑DM "Submit to my employer" path bypasses.

2. Submission routing falls through. In useExpenseSubmission.ts, a per‑diem SUBMIT-to-draft-workspace matches neither the workspace‑creating trackExpense branch (gated on !isPerDiemRequest) nor the submitPerDiemExpense branch (gated on action !== SUBMIT). It falls through to requestMoney, which cannot atomically create the draft Submit workspace and does not handle per diem custom units — so the optimistic report is created but the server round‑trip never resolves correctly, leaving the report in infinite loading with RBR errors.

Supporting evidence & data flow

• Per diem requires the Control plan: arePerDiemRatesEnabled → isControlPolicy(policy) (policy.type === CORPORATE), see PolicyUtils.ts. A Submit-plan workspace has no per diem custom unit, so canSubmitPerDiemExpenseFromWorkspace(policy) returns false.
• The new flow creates a CONST.POLICY.TYPE.SUBMIT workspace in useAutoCreateSubmitWorkspace.ts.
• An equivalent guard already exists for the "move expense to report" flow (warning modal when the destination lacks per diem): IOURequestEditReportCommon.tsx:197-234 — proving the pattern and the missing coverage in the new flow.

Flow: per diem expense created on a Control workspace → Control workspace deleted (transaction keeps its old customUnit/subrates) → "Submit to my employer" creates a Submit-plan workspace as the target → validator passes (only transaction-intrinsic checks) → "Create expense" submits per diem to a policy that can't process it → infinite loading + RBR.

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

Block per diem expenses from being submitted to a workspace that doesn't support per diem. Preferred: add a guard in useConfirmationValidation.ts (near the existing per diem checks) that returns an error when isPerDiemRequest && !canSubmitPerDiemExpenseFromWorkspace(policy), surfacing a clear "per diem is not available on this workspace" message. This is the single choke point the "Create expense" button flows through, so it covers all confirmation paths.

Ideally also prevent the "Submit to my employer" flow from offering/creating a Submit workspace as a per diem destination in the first place (so the user gets blocked earlier rather than at the final button), mirroring the existing workspace-picker filter and the move-expense guard.

What alternative solutions did you explore? (Optional)

Handling the case inside useExpenseSubmission.createTransaction (so per diem SUBMIT-to-draft-workspace is routed correctly) would fix the stuck state, but since per diem genuinely isn't supported on a Submit plan, blocking the submission with a clear error is the correct product behavior.

Confidence: High — code path confirmed end-to-end. Production logs could confirm the exact backend failure mode (silent client bail in requestMoney vs. server rejection of the per diem custom unit), but they aren't needed to locate the fix.

---

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

[MelvinBot]

🔍 Investigation Summary

Classification: Frontend bug
Causing PR: #94319 - "[Submit] Update "Submit to someone" to two options to allow for Submit workspace creation" by @abzokhattab (High confidence)
Related Issues: N/A

Recommendation: ROLL FORWARD (targeted guard)

The bug is a narrow edge case (per-diem expense routed into the brand-new Submit-workspace-creation flow), not core to the PR's feature. A reverting would remove an entire new user-facing flow, whereas a two-line guard closes the gap. Fix forward.

Assigned: @abzokhattab (PR author), @hungvu193 and @iwiznia (approving reviewers) from PR #94319
Labels: No changes. DeployBlockerCash kept (App-caused, blocks App deploy). No DeployBlocker present; nothing removed.

📋 Detailed Analysis

Evidence

• Version 9.4.34-12, reproducible on staging only, N/A on production — consistent with a bug introduced by a PR still on staging.
• PR [Submit] Update "Submit to someone" to two options to allow for Submit workspace creation #94319 (merged 2026-07-13) introduces the "Submit to my employer" flow that creates a draft Submit-plan workspace (CONST.POLICY.TYPE.SUBMIT) and moves the expense into it. It touches every file implicated here: useExpenseSubmission.ts, useConfirmationValidation.ts, Policy.ts, TrackExpense.ts, ReportUtils.ts, and the SUBMIT policy type.
• The new branch variable isSubmittingExpenseToDraftWorkspace is unique to this PR (introduced by its diff) and is exactly the code that mis-handles the per-diem case.
• Per diem requires the Control/Corporate plan (it needs a per diem custom unit). A freshly created Submit-plan workspace has no per diem custom unit, so this destination is fundamentally incompatible with a per-diem expense.

Verification

Affected files (blob 763218ccf3a286f440f26ee11af5bab42a8f4007):

1. src/pages/iou/request/step/confirmation/useExpenseSubmission.ts — the fall-through:

   • L1002-L1004: the trackExpense branch that would create the draft Submit workspace is gated on !isPerDiemRequest, so a per-diem request is excluded.
   • L1030-L1034: submitPerDiemExpense is gated on action !== CONST.IOU.ACTION.SUBMIT, so a SUBMIT action is excluded.
   • L1058: a per-diem + SUBMIT + draft-Submit-workspace request matches neither branch and falls through to requestMoney, which cannot create the draft workspace nor handle per diem → infinite skeleton + RBR reports on the LHN.

2. src/components/MoneyRequestConfirmationList/hooks/useConfirmationValidation.ts — no compatibility guard:

   • L280-L300: the only per-diem checks are sub-rate length and amount validity. Nothing verifies the destination policy supports per diem, so validation lets this through.

3. src/libs/OptionsListUtils/index.ts — the only real per-diem/policy guard, which this path bypasses:

   • L2339-L2342: canSubmitPerDiemExpenseFromWorkspace(policy) filters out per-diem-incompatible workspaces, but only in the workspace-picker option list. The self-DM "Submit to my employer" flow never goes through this picker.

4. src/libs/PolicyUtils.ts — the helper that confirms incompatibility:

   • L1902-L1906: canSubmitPerDiemExpenseFromWorkspace returns false unless the policy has an enabled per diem custom unit — which a Submit-plan draft workspace never has.

Root Cause

The new Submit-workspace-creation flow does not enforce plan compatibility for per diem. Per diem is a Control-plan feature, but the flow lets a per-diem expense target a to-be-created Submit-plan workspace. The request then matches none of the specialized branches in useExpenseSubmission and falls back to requestMoney, which is incapable of creating the draft workspace or submitting per diem, leaving the report stuck loading with RBR.

Fix-forward recommendation (concrete guard)

Block this combination at validation time so the user is prevented from confirming, mirroring the existing picker guard. In useConfirmationValidation.ts near L280, add a guard using canSubmitPerDiemExpenseFromWorkspace(policy) (already exported from PolicyUtils), e.g.:

if (isPerDiemRequest && !canSubmitPerDiemExpenseFromWorkspace(policy)) {
    return {errorKey: 'iou.error.perDiemNotSupportedForWorkspace'}; // add new copy string
}

This prevents the fall-through to requestMoney and surfaces a clear error instead of the skeleton/RBR state. The author/reviewers should confirm the exact copy key and whether the picker for the new self-DM "Submit to my employer" flow should also exclude Submit-plan destinations for per-diem expenses.