[Due for payment 2026-06-16] Expense - App freezes and becomes unresponsive after switching from Scan to Manual tab

[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.3.98-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: #91218
Email or phone of affected tester (no customers): jsodinjosdjsoinjsiojs@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:

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

1. Go to staging.new.expensify.com
2. Open FAB > Create expense > Scan.
3. Upload a receipt.
4. Click RHP back button.
5. Go to Manual tab.

Expected Result:

Manual tab will open.

Actual Result:

App freezes and becomes unresponsive after switching from Scan to Manual tab.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7170489_1780492411974.1.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Julia Ponikarchuk
Bug ID: 7170489

Issue Owner

Current Issue Owner: @mallenexpensify

[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/86bc7158f14808e8d8597935b0c1cd3355e3bcf293f734fd31ed54485c9e6f2e

[melvin-bot]

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

[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

TL;DR: The freeze is a pre-existing newManualExpenseFlow beta bug in the global-create (FAB) path — it is not a regression introduced by Expensify/App#91218. That PR only seeds participants for the workspace‑chat entry point, so its fix is a no‑op for the FAB flow in these repro steps. Reverting #91218 would not fix this freeze, and would re‑introduce the original bug (#90652). The correct action is a small forward‑fix.

Note: this only reproduces with the beta manually enabled via Onyx.merge('betas', ['newManualExpenseFlow']), which is why it's not reproducible in production.

Proposal

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

With the newManualExpenseFlow beta on, switching from the Scan tab (after uploading a receipt) to the Manual tab via the global FAB → Create expense entry point freezes the app.

What is the root cause of that problem?

Under the beta, the Manual tab embeds IOURequestStepConfirmation, whose auto‑assign useEffect re‑fires whenever the freshly‑rebuilt transaction has no participants, kicking off a cascade of writes (setMoneyRequestParticipants → setTransactionReport → navigation.setParams) that drives a render storm and hangs the tab.

PR #91218 prevents this by seeding participants up‑front in initMoneyRequest so the auto‑assign effect short‑circuits. But the seed only fires when the route has a real report. In the global‑create path the route report is empty (IOURequestStartPage.tsx:103), so useResetIOUType's defaultParticipants useMemo returns undefined, no participants are seeded, and the cascade fires unchecked.

The confirmation step already knows how to resolve participants for global create (selfDM / default‑expense‑policy fallback at IOURequestStepConfirmation.tsx:285-301) — useResetIOUType does not mirror that, so the seed is missing exactly where it's needed.

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

Extend useResetIOUType's defaultParticipants useMemo so that, when the beta is on and report is empty (global create), it mirrors the confirmation step's global‑create fallback — resolve participants from the default expense policy chat or selfDM (reusing shouldUseDefaultExpensePolicy / getPolicyExpenseChat / getMoneyRequestParticipantsFromReport, the same helpers used at IOURequestStepConfirmation.tsx:285-301). Those seeded participants then flow into initMoneyRequest, the auto‑assign effect short‑circuits on first render, and the cascade never starts.

Recommended secondary cleanups (not strictly required to unfreeze)

• setMoneyRequestParticipants merges only {participants} and does not set participantsAutoAssigned: true, so it lacks the same short‑circuit semantics as the seed path. Setting it there makes the behavior consistent.
• useResetIOUType.ts:141 passes an inline arrow to useFocusEffect (not wrapped in useCallback), so the focus‑effect body re‑runs on every render while focused. Guards bail in steady state, so this isn't the freeze driver, but wrapping it in useCallback removes redundant initMoneyRequest churn.

What alternative solutions did you explore? (Optional)

Revert #91218 — rejected. The freeze cascade lives entirely in pre‑existing code (IOURequestStepConfirmation's auto‑assign effect), which #91218 never touched (it changed only 3 files: useResetIOUType.ts, MoneyRequest.ts, IOURequestStartPage.tsx). Reverting would leave the freeze in place and re‑introduce #90652 (Manual tab showing the Scan confirm page in the workspace‑chat path).

Investigation details & confidence

• Confidence: High that this is a pre‑existing beta bug (not a Manual tab shows scan confirm page after uploading receipt on Scan and returning to Manual #91218 regression) and that revert is the wrong fix. High on the forward‑fix direction. Medium on the exact single hottest render loop — a React DevTools profiler trace of the Manual‑tab switch (or break‑on "Maximum update depth exceeded") would pinpoint the precise setState/Onyx.merge driving the loop.
• The global‑create transaction is built with no participants because MoneyRequest.ts:360 only seeds when defaultParticipants is non‑empty.
• The auto‑assign effect at IOURequestStepConfirmation.tsx:368-386 calls setMoneyRequestParticipants, then (for selfDM) setTransactionReport(..., {reportID: UNREPORTED_REPORT_ID}) and navigation.setParams({iouType: TRACK}) — the iouType flip ripples through tab/memo recomputation and remounts the Scan tab keyed by request type.

---

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

[thelullabyy]

Not reproducible to me for both MacOS Chrome and Safari on staging...

cc @dukenv0307 could you check it as well?

Screen.Recording.2026-06-03.at.08.48.39.mov

Screen.Recording.2026-06-03.at.08.46.22.mov