[$250] Expense - Unable submit distance expense to new user. Error shown.

[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?: No
If this was caught during regression testing, add the test name, ID and link from BrowserStack: https://test-management.browserstack.com/projects/2219752/folder/13176744/test-cases/41237164
Email or phone of affected tester (no customers): applausetester+062226f@applause.expensifail.com
Issue reported by: Applause Internal Team
Bug source: Regression TC Execution
Device used: iOS
App Component: Money Requests

Action Performed:

1. Launch App as sign in with applause.expensifail.com account
2. Click on the Global plus button (FAB)
3. Select "Track distance"
4. Select "Map" tab
5. Click on "Start" Enter any address > Click on "Stop" Enter any address
6. Click Next
7. Enter a new user email (use any domain besides @applause.expensifail.com for the new account) > Click "Create x.xx expense"

Expected Result:

Verify you're navigated to the chat with new user

Actual Result:

Navigate to WS and expense show error "There is a previously existing chat between these
users."

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7188145_1782177162226.ScreenRecording_06-22-2026_22.mp4

View all open jobs on GitHub

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

Issue Owner

Current Issue Owner: @thelullabyy

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022072591003593976054
• Upwork Job ID: 2072591003593976054
• Last Price Increase: 2026-07-02
• Automatic offers:
• thelullabyy | Reviewer | 111893477

[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/0124e57b49b68d693cdca2f8c13692515cd3b16fb9477c99ba3e2685906d7eae

https://platform.applause.com/services/links/v1/external/4a425091c1d3363adc4b6e0351680fdd296036b6179ab12346cf7b70aede5af8

[melvin-bot]

Triggered auto assignment to @danieldoglas (DeployBlockerCash), see https://stackoverflowteams.com/c/expensify/questions/9980/ for more details.

[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

Root Cause

This is a regression from #94134 "feat: remove isNewManualExpenseFlowEnabled beta flag" (merged 2026-06-22, merge commit f3a3a9c) — which lands in staging 9.4.17-0 but not production, exactly matching "Reproducible in staging?: Yes / production?: No".

Before that PR, the isNewManualExpenseFlowEnabled beta gated the default‑participant auto‑assignment. With the gate gone, this now runs for everyone: on a global‑create flow (FAB → Track distance), useDefaultParticipants resolves a default participant, and when the user has an auto‑reporting default expense policy that default is the Workspace policy‑expense chat (accountID: 0, isPolicyExpenseChat: true, see MoneyRequest.ts:494-504).

On the confirmation page, an ungated effect (IOURequestStepConfirmation.tsx:325-344) overwrites transaction.participants with that Workspace default whenever participants is momentarily empty:

if (hasTransactionParticipants || !hasDefaultParticipants) { return; }
setMoneyRequestParticipants(transaction.transactionID, defaultParticipants);

So the manually entered new user gets replaced by the Workspace, the request is built/navigated against the workspace chat, and the optimistic chat report it submits collides with an already‑existing chat — the backend rejects it with "There is a previously existing chat between these users." (that string is a Web‑Expensify/Auth message, not in App).

Recommended Fix

Because this is a DeployBlockerCash, the safest action is to revert #94134 (or re‑gate it behind the beta) to unblock the deploy.

For a targeted forward‑fix: the auto‑assign effect at IOURequestStepConfirmation.tsx:325-344 must not overwrite a user's explicitly selected participant. Default auto‑assignment should be skipped when the user reached confirmation with an already‑chosen participant (e.g. the Track → Submit conversion that carries a generated reportID), so it only applies to the truly "no participant chosen yet" case.

Investigation details & confidence

• Confidence: Medium‑High. Strong dated evidence for the offending PR (timing + staging‑only repro) and the Workspace‑default code path is verified in the current checkout. The exact final trigger — whether the new‑user participant is overwritten by the Workspace default vs. an optimistic 1:1 chatReportID being sent for an already‑existing chat — was not 100% disambiguated without runtime/network capture; both paths flow through MoneyRequestBuilder.ts getMoneyRequestInformation.
• isNewManualExpenseFlowEnabled no longer exists anywhere in src/ — confirming the beta was fully removed by feat: remove isNewManualExpenseFlowEnabled beta flag #94134.
• Flow: FAB → Track distance (isFromGlobalCreate, iouType TRACK) → Map start/stop → Next → participant picker (new user) → confirmation. The defaultParticipants (Workspace) overwrite happens at the confirmation step.
• To confirm in prod logs: pull the CREATE_DISTANCE_REQUEST write for a repro requestID and inspect chatReportID / participant accountID / policyID — check whether chatReportID resolves to a policy‑expense (Workspace) chat vs. a 1:1.

Related Issues

The quick scan surfaced no other open issue describing this exact symptom; this appears to be a fresh regression from #94134.

---

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

[trjExpensify]

I can repro this reliably.

CC: @thelullabyy