[Due for payment 2026-07-30] Expense - Returning from "Submit to my employer" if no workspace, leads to infinite loading

[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-0
Reproducible in staging?: Yes
Reproducible in production?: Yes
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+ib0024@applause.expensifail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Motorola MotoG60 / Android 12 (Hybrid app)
App Component: Money Requests

Action Performed:

Prerequisite: Use an expensifail account.
Prerequisite 2: Account has no workspaces and has Self DM.

1. Open the Expensify app.
2. Create a manual expense and submit it to Self DM.
3. Tap on "Submit to my employer"
4. Use device´s back button to return to chat.
5. Note that infinite skeleton loader is displayed.
6. Tap on back button on the top left corner.
7. Note that you land on "Inbox" intead of on chat.

Expected Result:

User should be able to return to chat from confirm page after selecting "Submit to my employer"

Actual Result:

Infinite skeleton loader is displayed when returning from confirm page to chat after selecting "Submit to my employer"

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7208318_1784050189352.Submit_it_4.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Svetlana Lazutkina
Bug ID: 7208318

Issue Owner

Current Issue Owner: @abzokhattab

[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/839de99bdc1510871da761a4efcc5c38fb952e123ba8fcdca0ada9b775e56215

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

Issue Analysis

Root Cause: This is a regression from PR #94319 (the "Submit to a friend / Submit to my employer" split). In the 0-workspace "Submit to my employer" path, a new submit2026 workspace + expense chat report is created and written only to REPORT_DRAFT, never to COLLECTION.REPORT. The confirmation screen then pre-inserts a full-screen ReportScreen for that draft-only reportID under the RHP (narrow layout / Android). When you press the device back button, that draft-only ReportScreen is revealed — but ReportActions reads the report only from COLLECTION.REPORT (never falling back to REPORT_DRAFT), so report is undefined and it renders the loading skeleton forever. PR #94319's new guard in ReportFetchHandler.tsx:154-160 deliberately skips openReport for draft-only reports, so COLLECTION.REPORT is never populated and the skeleton never resolves. The top-left back then lands on Inbox because goBack/goUp can't resolve the draft-only reportID to a real report and falls back to the sidebar.

Recommended Fix (targeted — preferred over full revert): Stop routing the underlying full-screen ReportScreen at the draft-only workspace expense-chat reportID. In createDraftWorkspaceAndNavigateToConfirmationScreen / the confirmation pre-insert in IOURequestStepConfirmation.tsx:523-578, pre-insert the origin Self DM (backTo) as the report shown behind the RHP instead of the draft-only reportID. That way device-back reveals a real, fully-loaded report. Keep the ReportFetchHandler guard — it exists to stop openReport from 403ing on the not-yet-persisted draft report.

Do not simply remove the ReportFetchHandler guard — that reintroduces the 403 it was added to prevent. And making ReportActions fall back to REPORT_DRAFT alone would clear the skeleton but leave the "back lands on Inbox" bug, so it must be combined with the navigation fix.

Investigation details & evidence

Data flow (0-workspace employer path):

1. Self-DM track-expense whisper → Submit to my employer, user has 0 workspaces (SUBMIT_2026 beta).
2. ReportUtils.ts:11563-11594 → filteredPoliciesCount === 0 → createDraftWorkspaceAndNavigateToConfirmationScreen(...).
3. createDraftWorkspace (Policy.ts:3278-3282) writes the expense chat report only to REPORT_DRAFT<expenseChatReportID> — no COLLECTION.REPORT entry until the server persists it after confirmation.
4. Confirmation RHP opens with :reportID = the draft-only expenseChatReportID and backTo = the Self DM.
5. On narrow layout, IOURequestStepConfirmation.tsx:561,578 pre-inserts a full-screen ReportScreen for the draft reportID under the RHP — isDestinationReportLoaded passes only because getReportOrDraftReport reads the draft.
6. Device back → RHP dismissed → underlying draft-only ReportScreen focused.
7. ReportFetchHandler.tsx:154-160 guard (if (!reportOnyx?.reportID && !!reportDraftOnyx?.reportID) return;) skips openReport → COLLECTION.REPORT stays empty.
8. ReportActions.tsx:46,72-79 reads only COLLECTION.REPORT → report === undefined → infinite ReportActionsLoadingSkeleton.
9. Top-left back → goBack/goUp can't resolve the draft-only reportID → falls back to the ReportsSplitNavigator sidebar = Inbox.

Why targeted over revert: PR #94319 also ships the whisper split (ChatActionableButtons, CONST, ROUTES, Policy defaults). A revert drops that whole feature. The failure is confined to the 0-workspace draft-report navigation, so a targeted navigation fix has a much smaller blast radius. A full revert of PR #94319 remains the lowest-risk fallback if a targeted fix can't be verified in time for the deploy.

Confidence: High — code evidence agrees end-to-end; the only medium-confidence detail is the exact goUp path that yields Inbox for the header back button, and whether this also reproduces on wide/web layout (the pre-insert is narrow-only, consistent with the Android-Hybrid-only report).

---

Next Steps for Contributor+ team:
To accept & fix: @MelvinBot implement [this](https://github.com/Expensify/App/issues/96117) to create a draft PR (targeted navigation fix).
To refine: @MelvinBot <your feedback>
To reject: Explain why you are rejecting this analysis (e.g. prefer a straight revert of PR #94319).

[MelvinBot]

🔍 Investigation Summary

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

Recommendation: REVERT (default) — with a viable targeted fix documented below

PR #94319 is confirmed in the 9.4.34 staging deploy (checklist #96044) and its diff introduces every code path that produces the infinite skeleton. Given deploy-blocker time pressure, a clean revert is the safest action; a small, well-scoped targeted fix is available if the author prefers to preserve the feature (see below).

Assigned: @abzokhattab (PR author), @hungvu193 and @iwiznia (approving reviewers) — already auto-assigned by melvin-bot; confirmed correct.
Labels: No change. DeployBlockerCash is correctly present (App PR caused it; reproduces on production) and is kept. No DeployBlocker (Web) label present, so none removed.

📋 Detailed Analysis

Evidence

• PR [Submit] Update "Submit to someone" to two options to allow for Submit workspace creation #94319 (merged 2026-07-13) is listed in StagingDeployCash Deploy Checklist: New Expensify 2026-07-14 #96044 for 9.4.34. Its diff touches exactly the files on the failure path: ReportFetchHandler.tsx, ReportUtils.ts (createDraftWorkspaceAndNavigateToConfirmationScreen + the 0-workspace employer branch), Policy.ts (createDraftWorkspace), and IOURequestStepConfirmation.tsx.
• No other PR in the release plausibly causes an infinite-loading-on-back regression scoped to the new "Submit to my employer" whisper option — that entire option is introduced by [Submit] Update "Submit to someone" to two options to allow for Submit workspace creation #94319.
• Reproduces on staging and production (production runs the same 9.4.34 candidate). Symptom is narrow-layout only (Android Hybrid), consistent with the pre-insert being gated on getIsNarrowLayout().

Verification (at HEAD be9be332d93dc277f735c79a3d6fdf5d6b8823eb)

1. Draft-only report is created — the 0-workspace employer branch calls createDraftWorkspaceAndNavigateToConfirmationScreen(...); createDraftWorkspace writes the expense chat only to COLLECTION.REPORT_DRAFT, never COLLECTION.REPORT.
2. Confirmation route :reportID is the draft-only report — ReportUtils.ts navigate call passes expenseChatReportID as :reportID, backToReport = undefined (5th arg), and the self-DM only as the backTo route (7th arg).
3. Pre-inserted full-screen report behind the RHP resolves to the draft-only report — IOURequestStepConfirmation.tsx:523: destinationReportID = (isSelfDMDestination ? selfDMReportID : (backToReport ?? routeDestinationReportID)) ?? selfDMReportID. Here the participant is the draft policy expense chat (not self-DM), so isSelfDMDestination is false and backToReport is undefined → destinationReportID = routeDestinationReportID = report?.reportID = the draft-only report. That value is used for the pre-insert at :575.
4. openReport is deliberately skipped for the draft-only report — ReportFetchHandler.tsx:158: if (!reportOnyx?.reportID && !!reportDraftOnyx?.reportID) { return; }. So COLLECTION.REPORT is never populated.
5. ReportActions renders skeleton forever — ReportActions.tsx:46 reads only COLLECTION.REPORT; :72 if (!report || ...) return <ReportActionsLoadingSkeleton />. Device back reveals this draft-only screen → infinite skeleton.

Root Cause

The device back button (unlike the explicit dismiss which honors Navigation.goBack(backTo)) reveals whatever full-screen report was pre-inserted under the RHP. #94319 pre-inserts the draft-only workspace expense chat (because backToReport was left undefined and the participant isn't the self-DM), and simultaneously guards openReport off for draft-only reports. The report therefore never lands in COLLECTION.REPORT, and ReportActions — which reads only COLLECTION.REPORT with no REPORT_DRAFT fallback — shows the skeleton indefinitely. The subsequent "top-left back lands on Inbox" is goUp failing to resolve the draft-only reportID and falling back to the sidebar.

Targeted fix (if not reverting)

Make the report pre-inserted behind the RHP be the origin self-DM, not the draft-only report. Concretely, plumb the origin reportID into backToReport (the 5th getRoute arg) at ReportUtils.ts:11398 — i.e. pass backToReportID as backToReport in addition to the backTo route — so that in IOURequestStepConfirmation.tsx:523 destinationReportID resolves to the real (fully-loaded) self-DM. Device back then reveals a real report instead of the draft.

Keep the ReportFetchHandler.tsx:158 guard — it exists to stop openReport from 403ing on the not-yet-persisted draft report; removing it reintroduces that error. Note that merely adding a REPORT_DRAFT fallback in ReportActions would clear the skeleton but leave the "back lands on Inbox" bug, so it is not sufficient on its own.

Confidence: High — code path verified end-to-end at HEAD. Remaining medium-confidence detail is the exact goUp chain that yields Inbox for the header back button.