[Due for payment 2026-07-01] [Due for payment 2026-06-30] Expense - Expense is created in another report with error when Submissions are disabled

[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.17-0
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: #94134
Email or phone of affected tester (no customers): djnosdjosjnosjdoi@gmail.co
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:

• Disable Submissions in Workflows.

1. Go to staging.new.expensify.com
2. Open self DM.
3. Send a message.
4. Open FAB > Create expense > Manual.
5. Enter amount.
6. Click Create expense.

Expected Result:

Expense will be created in self DM without issue.

Actual Result:

Expense is created in another report.
The report loads infinitely and shows skeleton header after reopening the report.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

To be added by Applause Leads

View all open jobs on GitHub

Applause Internal Information
Exported by: Mita Rachim
Bug ID: 7188144

Issue Owner

Current Issue Owner: @thelullabyy

[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/a48ebadeab8bf717b40f8813d6f8907b2e0d1520e535ce4965aa0e47c1ccf274

[melvin-bot]

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

[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: PR #94134 (which removed the isNewManualExpenseFlowEnabled beta) is the regression. Before it, useDefaultParticipants short‑circuited and returned [] when the beta was off, so the FAB → Create expense → Manual flow did not auto‑assign a report. The PR removed that early return, so the flow now always auto‑assigns the expense to a default‑expense‑policy report instead of the self DM the user started from. Because that destination report's data isn't loaded, the chat header is stuck on the skeleton forever.

Two things go wrong:

1. Wrong report. The FAB global‑create flow's source report is a freshly‑generated random reportID (not the self DM), so sourceReport resolves to undefined and the self‑DM branch never fires. The target is then decided entirely by shouldAutoReport = !!defaultExpensePolicy?.autoReporting || !!personalPolicy?.autoReporting. Disabling Submissions only sets the workspace's autoReporting=false — it does not touch the separate personal policy, whose autoReporting is OR'd in independently. So the expense is still routed to getPolicyExpenseChat(...) (the workspace chat = "another report") even though Submissions are off on the workspace.

2. Infinite skeleton. When the app navigates to that workspace chat, its report data/actions aren't in Onyx. HeaderView's isLoading = !report?.reportID || !title renders the skeleton, and ReportNotFoundGuard never falls back to a not‑found page because isLoadingInitialReportActions defaults to true and is only cleared by a completed OpenReport that is never fired/never resolves for this destination.

Recommended Fix: As a deploy blocker, the safest immediate unblock is to revert PR #94134. For the forward fix, the new manual flow's auto‑assignment in useDefaultParticipants should not silently route a global‑create / self‑DM‑initiated expense to a workspace report the user wasn't in — and whatever the destination, it must ensure OpenReport fires for it so the screen can't hang on the skeleton. The || !!personalPolicy?.autoReporting term at useDefaultParticipants.ts:65 is the specific reason the "Submissions disabled" precondition still lands on a workspace report.

Investigation details & data flow

Data flow

1. User views self DM → FAB → Create expense → Manual. The FAB generates a random reportID and starts the request with isFromFloatingActionButton=true.
2. In IOURequestStepConfirmation, sourceReport = getReportOrDraftReport(randomID) → undefined, so getMoneyRequestParticipantsFromReport(undefined) returns [].
3. useDefaultParticipants falls through to the default‑policy branch. shouldUseDefaultExpensePolicy is true for a user with a qualifying group default policy and does not depend on autoReporting, so auto‑assignment fires unconditionally post‑PR.
4. shouldAutoReport ORs the personal policy's autoReporting, so the target becomes the workspace policy expense chat even with workspace Submissions disabled.
5. The confirmation auto‑assign effect commits those participants; post‑create navigation opens that not‑loaded report → skeleton.

Why it's the inverse of the "expected" path: when shouldAutoReport is false, the target is the self DM and the expense correctly becomes a tracked/UNREPORTED expense — that's the expected result. The bug surfaces precisely when shouldAutoReport is forced true by the personal policy term despite the workspace's Submissions being off.

Open items worth a quick runtime confirm (would raise confidence to High):

• Confirm the personal policy's autoReporting is true for the affected tester (it's backend‑seeded; the App never sets it for personal policies).
• Confirm whether OpenReport is fired for the destination reportID (it can be suppressed for optimistic non‑policy chats in ReportFetchHandler), which distinguishes "never fired" vs "never resolved".

---

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

[trjExpensify]

Disabling Submissions only sets the workspace's autoReporting=false — it does not touch the separate personal policy, whose autoReporting is OR'd in independently. So the expense is still routed to getPolicyExpenseChat(...) (the workspace chat = "another report") even though Submissions are off on the workspace.

But this can be expected depending on the set up. The personalPolicy has this logic that if autoReporting is enabled on it (via Classic), and the group workspace does not, we'll still autoReport the expenses to the default workspace on creation.

I just checked the tester's personal policy and autoReporting isn't enabled currently 🤔