[Due for payment 2026-07-23] Web - Workspace - App crashes when open Distance rates or Receipt Partner

[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.34-8
Reproducible in staging?: Yes
Reproducible in production?: No
If this was caught during regression testing, add the test name, ID and link from BrowserStack: N/A
Email or phone of affected tester (no customers): leungbratt6@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Windows 10/Chrome
App Component: Workspace Settings

Action Performed:

1. Open the NewDot app with new account
2. Navigate to Workspace or create one
3. Turn on Distance rates and Receipt Partner in More Features
4. Click on Distance rates or Receipt Partner

Expected Result:

App opens the Distance rates or Receipt Partner page

Actual Result:

App crashes

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7208673_1784090394415!staging.new.expensify.com-1784090095350.txt

Bug7208673_1784090394411.crash_distance.mp4

View all open jobs on GitHub

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

[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/add37c3f591f6320f7e6e2eadfe057137bd8f2247f11a6dfab05dbfc4b8638b1

https://platform.applause.com/services/links/v1/external/c834ea8dbbcd9a38f2e20f8ec73b871b9117f03cc3be0e10d5d2c2a3a20d9f83

[melvin-bot]

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

[melvin-bot]

⚠️ Looks like this issue was linked to a Deploy Blocker here

If you are the assigned CME please investigate whether the linked PR caused a regression and leave a comment with the results.

If a regression has occurred and you are the assigned CM follow the instructions here.

If this regression could have been avoided please consider also proposing a recommendation to the PR checklist so that we can avoid it in the future.

[melvin-bot]

⚠️ Looks like this issue was linked to a Deploy Blocker here

If you are the assigned CME please investigate whether the linked PR caused a regression and leave a comment with the results.

If a regression has occurred and you are the assigned CM follow the instructions here.

If this regression could have been avoided please consider also proposing a recommendation to the PR checklist so that we can avoid it in the future.

[melvin-bot]

⚠️ Looks like this issue was linked to a Deploy Blocker here

If you are the assigned CME please investigate whether the linked PR caused a regression and leave a comment with the results.

If a regression has occurred and you are the assigned CM follow the instructions here.

If this regression could have been avoided please consider also proposing a recommendation to the PR checklist so that we can avoid it in the future.

[MelvinBot]

Issue Analysis

Root Cause: This is a fresh regression from the OXC React Compiler PR shipped in this release: Expensify/App#96115 ("Enforce Babel + OXC React Compiler memoization parity"), cherry-picked to staging as Expensify/App#96154 (merged 2026-07-15 01:26 UTC, ~3h before this bug was filed; not in production, matching "Reproducible in production?: No").

Both crashing pages are the ones that load a single illustration via useMemoizedLazyAsset(...) and render it straight into <Section icon={...}>:

• Distance rates: PolicyDistanceRatesPage.tsx:78 → :460 (CarIce)
• Receipt Partner: WorkspaceReceiptPartnersPage.tsx:70 → :312 (ReceiptPartners)

PR #96115 refactored useLazyAsset from a useRef to a useState pattern (commit e8ce86f8244, "Fix refs-during-render so SignInPage and useLazyAsset compile under OXC") so the file would compile/memoize under the web (OXC) compiler. On the OXC-compiled web build, the value returned by that hook and passed as the <Section icon> component resolves to a plain object instead of a valid SVG component, so React throws Minified error #130 — "Element type is invalid … got: object" and the page crashes. The crash log confirms this is the runtime error (no App symbols survive minification, but the error code + args[]=object is unambiguous).

Recommended Fix: Revert the cherry-pick Expensify/App#96154 (PR #96115) from staging to clear the deploy blocker. For the targeted follow-up fix, the useLazyAsset ref→state change (useLazyAsset.ts:76, useMemoizedLazyAsset:89) needs to be reworked so the resolved asset is a valid component under OXC before it reaches <Section icon>.

Investigation details, evidence & alternatives considered

Evidence chain

• Version 9.4.34-8 crashes on staging, not in production → regression introduced this release.
• Runtime error from the attached log: Minified React error #130 … args[]=object ("Element type is invalid … got: object") — a component being rendered is an object/undefined.
• Timeline: [CP Stg] Enforce Babel + OXC React Compiler memoization parity #96115 merged 00:48 UTC, cherry-picked as 🍒 Cherry pick PR #96115 to staging 🍒 #96154 at 01:26 UTC; bug filed 04:46 UTC.
• useMemoizedLazyAsset (single-asset variant) is used by only 4 workspace pages; the two that render its result directly as a <Section icon> are exactly the two reported as crashing. This explains why these specific pages break while most other workspace pages don't.
• The relevant diff (commit e8ce86f8244, in [CP Stg] Enforce Babel + OXC React Compiler memoization parity #96115): assetRef.current (a useRef) → asset/setAsset (a useState), with the return changed to asset: isLoaded ? asset : undefined.

Confidence: High on the culprit PR (two independent code investigations converged on #96115/#96154; timeline + the "only these pages" discriminator + the web-only/OXC framing all agree). Medium on the precise mechanism — the exact element React sees as object (the lazy illustration vs a memo-wrapped shared component such as Button/ScreenWrapper, which #96115 also touched) can be pinned from the Sentry componentStack for staging new.expensify@9.4.34-8 filtered to error #130. Either way the resolution is the same revert.

Alternative considered & ruled out: PR #96129 (revert of the free-trial countdown modal) also touched illustrations.chunk.ts, but it only removed the unrelated ArmWithCardPos illustration — CarIce and ReceiptPartners are still exported, so a missing-asset/deleted-export cause is ruled out.

---

Next Steps: Reply with @MelvinBot implement this to open a draft revert PR for #96154, or @MelvinBot <your feedback> to refine this analysis.

[MelvinBot]

🚨 Deploy Blocker Investigation

Culprit (High confidence): Expensify/App#96115 — "[CP Stg] Enforce Babel + OXC React Compiler memoization parity" (merge commit 11682df, merged 2026-07-15 00:48 UTC), shipped to this staging build via cherry-pick Expensify/App#96154 (merged 01:26 UTC). Both are on the current StagingDeployCash checklist (Expensify/App#96044) and still unchecked. Timeline fits: bug filed ~3h after the cherry-pick, and neither PR is in production ("Reproducible in production?: No").

Recommended resolution: REVERT the staging cherry-pick Expensify/App#96154 to clear the blocker. ⚠️ Caveat: #96115 was itself the fix for the earlier OXC deploy blockers #96054/#96086/#96092, so reverting reopens those. The durable path is a targeted follow-up (roll-forward) that reworks the useLazyAsset ref→state resolution so the asset is a valid component under OXC before it reaches <Icon src>, then re-land.

Root cause: #96115 refactored useLazyAsset.ts from a useRef to a useState pattern so it would stop violating Rules-of-React and get memoized by the OXC (web) compiler. The two crashing pages are exactly the two that load a single illustration via useMemoizedLazyAsset(...) and render it directly as a header icon component — so on the OXC-compiled web build the value handed to <Icon src> resolves to a plain object instead of the SVG component function, producing React error #130 ("Element type is invalid … got: object") from the crash log.

📝 Correction to my earlier comment: the render site is <HeaderWithBackButton icon={…}> (which forwards the value as src into <Icon src={icon}>), not <Section>. The mechanism is unchanged.

Suggested assignees (from the culprit PR): roryabraham (author), chuckdries and jasperhuangg (approving reviewers).

Evidence & smoking gun

Render sites (SHA 91e5699):

• Distance rates — CarIce loaded at PolicyDistanceRatesPage.tsx:78, rendered at :460
• Receipt Partner — ReceiptPartners loaded at WorkspaceReceiptPartnersPage.tsx:70, rendered at :312

The hook change (assetRef.current → useState, return at useLazyAsset.ts:76).

Smoking gun — the PR's eslint.seatbelt.tsv diff for this file:

-"../../src/hooks/useLazyAsset.ts"  "react-hooks/refs"                2
+"../../src/hooks/useLazyAsset.ts"  "react-hooks/set-state-in-effect" 1

Before #96115, the file had react-hooks/refs violations (a ref read during render). OXC bails the entire file on such violations, so the module shipped unmemoized on web (current production behavior). #96115 moved the asset into useState so OXC would memoize it — and that behavior change is what regressed these pages. On web, SVGs compile to component functions via @rsbuild/plugin-svgr with exportType: 'default', so a correctly-resolved asset would be a function; error #130 with object confirms the wrong value is reaching <Icon src>.

Confidence: High on the culprit PR; Medium-High on the exact micro-mechanism — pinning the precise element React sees as object (the lazy illustration vs. one of the memo-wrapped shared components #96115 also touched, e.g. Button) would need the un-minified component stack from Sentry for staging 9.4.34-8 filtered to error #130. The resolution is the same either way.

Alternative ruled out: #96129 (revert of the free-trial countdown modal) also edits illustrations.chunk.ts but only removes the unrelated ArmWithCardPos illustration; CarIce and ReceiptPartners remain exported.

Labels: No change — keep DeployBlockerCash; there is no DeployBlocker label present and none should be added.

---

Next Steps: Reply with @MelvinBot implement this to open a draft revert PR for #96154, or @MelvinBot <your feedback> to refine this analysis.