App crashes when user tap Approve Report

[applause-bot]

If you haven’t already, check out our contributing guidelines for onboarding. To join our Slack channel, fill out this form.

---

Version Number: 9.4.77-1
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://github.com/Expensify/Mobile-Expensify/pull/14115
Email or phone of affected tester (no customers): gocemate+buzz@gmail.com
Issue reported by: Applause Internal Team
Bug source: Pull Request QA execution
Device used: iphone 11/26.2
App Component: Other

Action Performed:

1. Account A is logged on iOS app
2. Account A creates Submit workspace in Old Dot
3. Account A goes to New Dot and invite User B as a editor of the workspace
4. Account B from other device goes to the workspace chat and submit manual expense
5. Account A goes to Old Dot> On the Here's the list of reports that need your attention card tap Begin review> Approve the expense to reach the Final Review screen> Tap Approve Report

Expected Result:

App switches to NewDot showing that report, rather than approving it.

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

Bug7259191_1789372099946.ScreenRecording_09-14-2026_09-26-17_1.mp4

View all open jobs on GitHub

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

Issue Owner

Current Issue Owner: @abzokhattab

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

https://platform.applause.com/services/links/v1/external/11c79bb952a2c144f0f536ab338172633cb8bf55c8930ef5d3f58ce27fc6bb4f

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

Triggered auto assignment to @stitesExpensify (DeployBlockerCash), see https://stackoverflowteams.com/c/expensify/questions/9980/ for more details.

[melvin-bot]

💬 A slack conversation has been started in #expensify-open-source

[MelvinBot]

🔍 Investigation Summary

Classification: Frontend bug (client-side crash in the OldDot side of the HybridApp — blocks the App deploy, not a backend issue)
Causing PR: Mobile-Expensify#14115 — the PR this bug was filed against during PR QA (Medium confidence — see caveat below)
Related Issues: None identified

Recommendation: REVERT

This is a staging-only crash in a flow that is being newly introduced by the very PR that was under QA when the bug was found, and that PR is still unchecked on the 9.4.77 deploy checklist. Reverting it (and bumping the submodule back) is the cleanest way to unblock the deploy; a roll-forward fix is fine instead if the author can land it quickly.

Assigned: No change — I could not resolve the author/reviewers of the causing PR from this environment (see caveat). @stitesExpensify (already assigned as DeployBlockerCash owner), please loop in the author of the linked PR.
Labels: No changes. DeployBlockerCash is kept — this is a client-side crash and it is not reproducible on production. DeployBlocker was not present, so nothing to remove.

📋 Detailed Analysis

Evidence

• Staging only, production clean. 9.4.77-0, reproducible on staging, not reproducible on production — so the cause is something newly landed in this release.
• iOS App only. Not reproducible on any web/mWeb platform, which rules out the shared NewDot web code paths and points at the native mobile client.
• The reporting context is the strongest signal. Bug source is "Pull Request QA execution" and the linked PR is Mobile-Expensify#14115. QA was exercising exactly this PR when the crash happened.
• The Expected Result describes new behavior. "App switches to NewDot showing that report, rather than approving it" is not the pre-existing behavior of the OldDot Final Review → Approve Report button; it is the behavior being introduced. The crash is in that new hand-off path.
• The PR is on this release and still unchecked on the deploy checklist (Deploy Checklist: New Expensify 2026-09-11 #100992), which lists it among the Mobile-Expensify PRs shipping in 9.4.77.

Verification

I reviewed every Expensify/App PR on the 9.4.77 checklist (#100992) and none of them touch this code path. For completeness, the merged App PRs in this release cover: Onyx connect() cleanups in ReportUtils, broken-card connection messaging, SmartScan hotel nightly-rate violations, the rulesRevamp beta removal, a11y "Save button" gating PRs, HR sync results screen, workspace add-work-email pages, domain admins pending requests, Search back navigation and has: filters, PolicyCategoriesProvider/PolicyTagsProvider removal, folder attachment errors, a keyboard-controller bump, Spotnana tripData NVP reads, "Create a rule" gating, Chronos OOO styles, plus several No-QA/tooling/typecheck/lint PRs.

I also checked the NewDot side of the OldDot→NewDot hand-off in Expensify/App:

• src/libs/actions/HybridApp/index.ts only implements the NewDot → OldDot direction (closeReactNativeApp) plus settings parsing. There is no App-side code that initiates a "switch to NewDot on report approval".
• src/DeepLinkHandler.tsx is the receiving end (Linking.getInitialURL() / url listener → openReportFromDeepLink). For this crash to originate there, the app would have to reach NewDot first — but the reported symptom is a crash instead of the switch, i.e. the crash happens before/at the hand-off, on the OldDot side.

So the fix does not belong in Expensify/App JS; it belongs in the native OldDot client.

Caveat on verification: I did not have read access to the Expensify/Mobile-Expensify repository from this environment, so I could not read the diff of the linked PR or pin the crash to a specific line. The attribution above is therefore based on release-timeline and QA-context evidence rather than on a code diff, which is why I am calling it Medium rather than High confidence. Someone with access should confirm against the diff and the iOS crash report before the revert lands.

Root Cause

Not fully pinned down. This appears to be an internal/native-client issue in the OldDot approval → NewDot hand-off, and a separate internal investigation is needed to confirm the exact crash site. The shape of the failure — a crash at the moment the approval flow is supposed to redirect into NewDot — is consistent with the hand-off being attempted before the data it needs to build the NewDot destination is available, which would matter specifically in this repro because the workspace was created in OldDot and the expense was submitted by a second account from another device.

Things worth checking when reproducing:

1. The iOS crash log / Sentry entry for 9.4.77-0 at the moment "Approve Report" is tapped in the Final Review screen.
2. Whether the crash still occurs when the approver created the report themselves (vs. a report submitted by another member), which would isolate the missing-data hypothesis.
3. Whether reverting the linked PR restores the pre-existing approve-in-OldDot behavior cleanly.

[mountiny]

@MelvinBot is that functionality behind beta?

[MelvinBot]

No — it's not behind a beta. The OldDot→NewDot redirect on Approve Report is gated on the workspace plan type being Submit (submit2026), not on any beta, NVP, or feature flag. There's no CONST.BETAS entry, no canUse* helper, and no isBetaEnabled() call anywhere on this path in App.

Practical consequence: there is no toggle to dark-launch or disable this. Every user approving a submit2026 report from OldDot mobile on 9.4.77 hits the new path, so reverting Mobile-Expensify#14115 (plus the submodule bump) is the only off-switch.

Evidence

The feature is the fix for #100598 — "[Submit] HybridApp OldDot has no upgrade paywall when approving Submit plan reports". Its Solution reads: "Reroute users from HybridApp OldDot to NewDot when they tap Approve on a Submit 2026 workspace report." jponikarchuk confirmed the link to this deploy blocker in a comment there. That matches the repro exactly — step 2 creates a Submit workspace. Parent feature is #87265 "[Submit] Upgrade on Approval flow (Wave 3)", also not beta-gated.

Worth noting: #100598 says it was itself discovered "while fixing this HybridApp crash where user tries to approve a report coming from a Submit 2026 policy" — so this is the second crash in this same flow.

All references at App SHA f777fabb:

What	Where
The NewDot interception the OldDot reroute is meant to reach. Condition is isSubmitPolicy(...) alone — no beta check here or in its callers	src/libs/actions/IOU/ReportWorkflow.ts:487-494
isSubmitPolicy is a plain plan-type read: policy?.type === CONST.POLICY.TYPE.SUBMIT	src/libs/PolicyUtils.ts:1439-1441
Full CONST.BETAS list — nothing for this redirect, Submit plan, or upgrade-on-approval (ASAP_SUBMIT / BULK_SUBMIT_APPROVE_PAY are unrelated)	src/CONST/index.ts:1082-1113
Permissions.ts exports only canUseLinkPreviews, canUseTrackFlows, canUsePrivateNotes, isBetaEnabled — no hybrid/approval helper	src/libs/Permissions.ts:69-74
App's receiving side of the hand-off is route-agnostic and ungated — OldDot supplies the initial URL	src/setup/hybridApp/index.native.ts:6-11
isSingleNewDotEntry is the only flag OldDot sets for this hand-off — a mode marker (suppress onboarding, exit back to OldDot), not a permission	src/types/onyx/HybridApp.ts:32-33
The only NewDot↔OldDot gating vocabulary in App is the migration NVP nvp_tryNewDot, which controls whether a user can leave NewDot for OldDot at all — it does not gate this redirect	src/libs/TryNewDotUtils.ts:10-53

Also confirmed by absence: src/libs/actions/HybridApp/index.ts and src/libs/HybridApp.ts implement only the NewDot→OldDot direction (closeReactNativeApp, signInToOldDot), and the native bridge spec in @expensify/react-native-hybrid-app has no approve/redirect method. Nothing in App initiates or authorizes this redirect.

Caveat: I have no read access to Mobile-Expensify, Auth, or Web-Expensify from this environment, so I can't byte-verify that the native side didn't add a beta check on top of the plan-type check. High confidence there's no App-side beta; someone with access should grep the #14115 diff for beta / isBetaEnabled in the approve path to rule out an additional gate, and check Auth's betas enum for anything Submit-approve related.

---

Next Steps: Reply with @MelvinBot <your feedback> to refine this.

[mountiny]

@MelvinBot yeah but customers already have access to the submit2026 workspace types, right?

[MelvinBot]

Yes — you're right, and it makes this worse, not better. submit2026 is GA on production today (production is aff1b3d / 9.4.76-1, and SUBMIT: 'submit2026' is at src/CONST/index.ts:4319 on that branch). Customers already have these workspaces.

So my earlier "not behind a beta" answer was the narrow question. The blast radius answer is:

Every existing Submit-plan customer whose approver uses iOS HybridApp hits this crash the moment 9.4.77 ships. The redirect fires on plan type alone, and the plan type is already out there.

And the crash sits on the Submit plan's monetization funnel, not a side path. The public help site documents tapping Approve as the upgrade trigger: "If your approver clicks Approve, they're prompted to upgrade the workspace to a paid plan before they can complete the approval" (Submit-Workspace.md:148). That is the exact tap that crashes. It also lands on approvers who are often brand-new to Expensify, since the doc has submitters invite them in as Editors.

Recommendation unchanged, confidence raised: revert Mobile-Expensify#14115 + submodule bump. There's no flag to turn this off and no small population to absorb it.

Evidence that Submit is GA, not gated

Verified at App f777fabb unless noted.

Claim	Evidence
Shipped to production, not just staging	production = aff1b3d1ed520ade7cdf4e40bab4d4c9cac096d4, package.json version 9.4.76-1. SUBMIT: 'submit2026' present at src/CONST/index.ts:4319; isSubmitPolicy, useAutoCreateSubmitWorkspace.ts, DynamicWorkspaceOverviewPlanTypePage.tsx and the help article all exist at ref=production too
No beta constant exists at all	src/CONST/index.ts:1082-1113 — the only "submit" beta is ASAP_SUBMIT, an unrelated instant-submit feature
No permission helper	src/libs/Permissions.ts:66-71 exports only canUseLinkPreviews, canUseTrackFlows, canUsePrivateNotes, isBetaEnabled
Publicly advertised as free-for-anyone	Submit-Workspace.md:16 — "Anyone can create a free Submit workspace." Also reachable from the public pricing page per the same article

Four ungated creation entry points, so the population is not small:

1. Onboarding — "Submit expenses to my employer" is in selectableOnboardingChoices with no beta filter (BaseOnboardingPurpose.tsx:121-129), calling useAutoCreateSubmitWorkspace.ts:86.
2. Track-expense whisper — telling detail: the "Submit to my employer" button at ChatActionableButtons.tsx:246 sits outside the Permissions.canUseTrackFlows() gate that starts at line 252. That gate is hardcoded off and covers only "Categorize it" / "Share with my accountant". Submit was deliberately left live while its siblings are disabled.
3. Email deeplink — an intent=submit handler auto-creates the workspace on arrival (SubmitIntentDeeplinkHandler/index.tsx:15-19), i.e. these links are actively sent to customers.
4. Pricing page → Submit plan → Get started, per the help article.

The redirect predicate itself is still plan-type only — isSubmitPolicy is a bare policy?.type === CONST.POLICY.TYPE.SUBMIT.

Caveat: I still have no read access to Mobile-Expensify, Auth, or Web-Expensify, so I can't rule out a native-side or Auth-side gate layered on top, and I can't give you a hard count of existing submit2026 policies. Someone with backend access could size it exactly with a count of type='submit2026' policies plus iOS HybridApp approve actions against them — but for a revert decision the GA status above should be enough.

---

Next Steps: Reply with @MelvinBot <your feedback> to refine this.

---

view run · no recording available