Expense - Participant list appears and disappears after opening Create expense flow

[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.41-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: #96228
Email or phone of affected tester (no customers): sdsjodijnsdojsosjio@gmail.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:

• Create a workspace and disable Submissions in Workflows settings.

1. Go to staging.new.expensify.com
2. Open FAB > Create expense.

Expected Result:

Participant list will not appear after opening Create expense flow.

Actual Result:

Participant list appears and disappears after opening Create expense flow when Submissions are disabled.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7213093_1784599468586.6.mp4

View all open jobs on GitHub

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

[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/3ccc9173cbd8225071236bacab12395908acd30e5b7dca42f955e4495ed20982

[melvin-bot]

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

[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

Please re-state the problem that we are trying to solve in this issue.

When Submissions are disabled on the workspace, opening FAB → Create expense briefly flashes the participant (recipient) list before it auto-closes. The step should never appear — the expense should silently auto-assign to a default destination.

What is the root cause of that problem?

Deploy blocker introduced by #96228 ("remove isNewManualExpenseFlowEnabled beta flag"). That PR made the embedded-confirmation + auto-opening participant picker the default for everyone, and the auto-open decision races with the async resolution of the default participant.

IOURequestStepConfirmation decides whether to auto-open the picker purely from whether default participants are currently populated — it has no "still loading" state:

Evidence (file:line)

• The picker auto-opens whenever defaultParticipants is empty: IOURequestStepConfirmation.tsx:299-307 drives visibility at :312-316.
• Once defaults resolve, an effect assigns them and the picker closes: IOURequestStepConfirmation.tsx:414.
• Default resolution depends on the Submissions setting: useDefaultParticipants.ts:70-71 — shouldAutoReport is autoReporting. With Submissions disabled it takes the selfDMReport branch, which comes from useSelfDMReport.ts:19 and settles a render or two later than the policy-expense-chat branch used when Submissions are enabled.

So on the first render(s) defaultParticipants is empty → shouldAutoOpenParticipantPicker is true → the list renders. A beat later the self-DM default resolves, the auto-assign effect fires, and the picker closes. That window is the visible "appears and disappears" flash. It only reproduces with Submissions disabled because the self-DM branch is the slow-to-resolve one; the enabled (policy chat) branch is already in Onyx, so there's no empty window.

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

Don't treat "defaults not yet resolved" as "no defaults." Gate the auto-open so the picker only opens once we know default resolution is actually complete and still empty:

• Add a loading/settled signal to useDefaultParticipants (e.g. surface whether the underlying Onyx sources — defaultExpensePolicy / selfDMReport — have loaded), and require it in shouldAutoOpenParticipantPicker at IOURequestStepConfirmation.tsx:299-307, so it stays false until defaults have settled.

Fastest path to unblock deploy

Since this is a deploy blocker, the safest immediate action is to revert #96228 (or re-gate the new flow behind the beta) and land the loading-guard fix as a follow-up.

Related issues

No open duplicates found.

---

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

[thelullabyy]

@MelvinBot Please open PR to fix the issue (Do not revert)