[Due for payment 2026-06-02] Expense - Two self DMs are selected in participant list when submissions are disabled

[lanitochka17]

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.74-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: #87920
Email or phone of affected tester (no customers): sdsdjoijdoisnjodis@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Mac 26.2 / Chrome
App Component: Money Requests

Action Performed:

Precondition:

• Run Onyx.merge('betas', ['newManualExpenseFlow']); in console.
• Disable Submissions in Workflows setttings.

1. Go to staging.new.expensify.com
2. Open FAB > Create expense > Manual.
3. Click To field.
4. Click RHP back button.
5. Enter amount and click Create expense.

Expected Result:

In Step 3, only one self DM will appear in participant list.
In Step 5, expense will be created in self DM.

Actual Result:

In Step 3, two self DMs appear in participant list. Both are selected.
In Step 5, expense is not created. The opened report loads infinitely.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7154007_1778761308592.22.mp4

Bug7154007_1778761354849.022.mp4

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @ChavdaSachin

[melvin-bot]

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

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

[OSBotify]

Investigation Summary

Classification: Frontend bug
Causing PR: #87920 - "Feat: Manual expense flow UI refactor - r3" by @ChavdaSachin (High confidence)
Related Issues: #82586 (parent feature issue)

Recommendation: REVERT

PR #87920 introduced a new manual expense flow that is causing duplicate self-DM entries in the participant list and infinite loading on expense creation. The fix requires changes to this App PR.

Assigned: @ChavdaSachin (PR author), @ShridharGoel @puneetlath (approving reviewers) from highest-confidence causing PR only
Labels: DeployBlockerCash kept (frontend bug in App). No label changes made.

Details

Evidence

• The melvin-bot auto-assigned the issue to PR Feat: Manual expense flow UI refactor - r3 #87920, identifying it as the recently merged causing PR
• PR Feat: Manual expense flow UI refactor - r3 #87920 ("Feat: Manual expense flow UI refactor - r3") was merged on 2026-05-13 and is listed in the current StagingDeployCash checklist (issue Deploy Checklist: New Expensify 2026-05-13 #90562 for version 9.3.74-1)
• The bug is staging-only ("N/A - new feature, doesn't exist in prod"), gated behind the newManualExpenseFlow beta flag introduced by this PR
• The bug requires the newManualExpenseFlow beta to reproduce, which this PR implements

Verification

• Affected files from the PR: src/components/MoneyRequestConfirmationList.tsx, src/pages/iou/request/step/IOURequestStepConfirmation.tsx, src/components/ParticipantPicker.tsx, src/pages/iou/request/step/IOURequestStepParticipants.tsx
• These files are the exact code paths involved in the manual expense participant selection flow
• The PR modifies getMoneyRequestParticipantsFromReport call sites in both MoneyRequestConfirmationList.tsx and IOURequestStepConfirmation.tsx

Root Cause

PR #87920 introduced two separate participant-defaulting code paths that interact incorrectly:

1. In IOURequestStepConfirmation.tsx (line ~263): a defaultParticipants useMemo computes self-DM participants when none are set, and a useEffect (line ~357) calls setMoneyRequestParticipants(transactionID, defaultParticipants) to persist them to Onyx.

2. In MoneyRequestConfirmationList.tsx, the PR previously added (and a later commit in the same PR partially refactored) a defaultParticipantOptions memoized value that also derived self-DM participants when selectedParticipants.length === 0.

When the user navigates to the "To" field and presses back without selecting a participant, the state transitions through conditions that trigger both paths simultaneously. The shouldForceTopEmptySections flag causes the "To" section to always render even when shouldHideToSection would normally suppress it. Combined with the self-DM fallback logic running in both IOURequestStepConfirmation and MoneyRequestConfirmationList, this results in the self-DM report participant being added twice to the displayed list. Both entries are marked as selected: true, and when "Create expense" is called, onConfirm receives a malformed participant list (duplicate self-DM), causing the expense creation to fail and the report to load infinitely.