Expense - App crashes on creating empty report after deleting default workspace second time.

[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: V9.4.44-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/test-runs/65568275/folder/13176730/41237110/1585993667
Email or phone of affected tester (no customers): dreamnitethedragon+vegst@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Redmi note 10s android 13
App Component: Money Requests

Action Performed:

1. Launch app
2. Onboarding via track business expense
3. Go to workspace settings
4. Toggle on forced offline
5. Create new workspace and delete default workspace
6. Create a empty report
7. Navigate back to workspace settings and create new workspace
8. Delete default workspace
9. Create an empty report

Expected Result:

App must not crash on creating empty report after deleting default workspace second time.

Actual Result:

App crashes on creating empty report after deleting default workspace second time.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7216287_1784887623057.Screenrecorder-2026-07-24-15-26-44-715.mp4

Bug7216287_1784887913048!Crash.txt

View all open jobs on GitHub

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

[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/0213a37d1006a1c5efc8379a5b80966430a274ab24101ee875011ff3469685e6

https://platform.applause.com/services/links/v1/external/3f79912da53967f32308738cbe8cd92878a950a18aca2f083f07ab206660a56b

[melvin-bot]

Triggered auto assignment to @mollfpr (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

ℹ️ This crash is the native counterpart of the already‑fixed Maximum update depth exceeded loop (Expensify/App#96411, Expensify/App#96370). PR Expensify/App#96720 (merged 2026‑07‑22, present in v9.4.44) fixed it on web but not on native, which is why it still reproduces on Android/iOS.

What is the root cause of that problem?

Creating a second empty report on a workspace that already owns one opens a confirmation modal, and that modal is opened from an effect whose dependency is an unmemoized callback — producing an infinite re‑render loop that React aborts with Maximum update depth exceeded (a hard crash on native).

Deleting the default workspace forces the "Create report" flow through the workspace‑selector page. There, selectPolicy creates directly the first time, but on the second empty report it takes the setPendingPolicySelection(...) branch, which arms this effect:

useEffect(() => {
    if (!pendingPolicySelection) return;
    openCreateReportConfirmation();
}, [pendingPolicySelection, openCreateReportConfirmation]);   // ← callback identity in deps

(DynamicNewReportWorkspaceSelectionPage.tsx:186-192)

openCreateReportConfirmation is a plain arrow function (useCreateEmptyReportConfirmation.tsx:79) whose identity depends on the values from useConfirmModal / ModalContext. Opening the modal calls setModalStack, which re‑renders ModalProvider and produces a new provider value object (ModalContext.tsx:138) → consumers re‑render → new openCreateReportConfirmation identity → the effect re‑fires while pendingPolicySelection is still set → the modal reopens → loop.

Why v9.4.44 still crashes on native even though Expensify/App#96720 is in the build: that PR stabilized the ModalContext value by moving resolveModal to a modalStackRef and relying on React Compiler to auto‑memoize the provider value. Per this repo's compiler setup, the web (OXC) and native (Babel) compilers "do not always agree, so a file can be memoized on one platform but not the other." The web build got the memoization and stopped looping; the native build did not, so the loop — and the crash — survive on Android and iOS. This also explains "Reproducible in production: No" — the empty‑report‑confirmation path only exists on staging.

Evidence & investigation details

• Repro is functionally identical to Expensify/App#96370 (iOS) and the web report Expensify/App#96411: make a non‑default workspace the effective default (by deleting the default), then create the same workspace's empty report twice.
• The Expensify/App#96720 ModalContext ref‑fix is present in the v9.4.44 checkout (modalStackRef at ModalContext.tsx:57, resolveModal reads modalStackRef.current.modals at :98) — yet the crash still reproduces, confirming the fix is incomplete for native.
• showConfirmModal/closeModal come from useConfirmModal, which wraps the ModalContext value; none are wrapped in explicit useCallback/useMemo, so their stability depends entirely on the compiler.
• The direct createNewReport path itself is null‑safe against a deleted/undefined active policy, so this is a render‑loop crash, not a null‑deref.
• Closed alternative fixes on Expensify/App#96411 — PR Expensify/App#96481 (page‑level ref) and PR Expensify/App#96484 (useEffectEvent) — targeted exactly this effect before Expensify/App#96720 was chosen instead.

Not runtime‑confirmed: I have not pulled a crash stack for this specific report, so I can't be 100% certain the native crash message is literally Maximum update depth exceeded vs. another symptom of the same loop. A Sentry/BrowserStack stack from the v9.4.44 session would confirm decisively.

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

Make the fix compiler‑independent instead of relying on React Compiler memoization that only holds on web:

1. Explicitly memoize the ModalContext provider value with useMemo, and wrap showModal/closeModal/resolveModal in useCallback in ModalContext.tsx, so the value is stable on all platforms.
2. Belt‑and‑suspenders at the trigger site: remove openCreateReportConfirmation from the effect's dependency array in DynamicNewReportWorkspaceSelectionPage.tsx:186 — call it via a useEffectEvent/ref so the effect only depends on pendingPolicySelection (this is the approach the closed PR Expensify/App#96484 used).

Either change alone should stop the loop; doing both removes the dependency on cross‑platform compiler behavior. Since this is a deploy blocker, option 1 fixes the root shared component; option 2 hardens the specific crash path.

What alternative solutions did you explore? (Optional)

Reverting Expensify/App#96720 is not appropriate — it's a partial fix, and reverting would re‑break web. Wrapping only openCreateReportConfirmation in useCallback is insufficient on its own because its dependencies (showConfirmModal/closeModal) are themselves unstable unless the ModalContext value is memoized.

---

Related issues: Expensify/App#96411 (web, fixed by PR Expensify/App#96720), Expensify/App#96370 (iOS, same loop, still open). These three are the same underlying bug.

---

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

[mollfpr]

@dmkt9 @jayeshmangwani could you check this blocker? It seems related to the PR #96720

[dmkt9]

@dmkt9 @jayeshmangwani could you check this blocker? It seems related to the PR #96720

Hi @mollfpr, I've just taken a look. It seems this bug was introduced by #96700. After reverting that PR, I can no longer reproduce the issue.

[aimane-chnaif]

@dmkt9 are you able to reproduce on latest main?