Subscription - App freezes on downgrade workspace page

[lanitochka17]

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.37.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: Exploratory around https://test-management.browserstack.com/projects/2219752/test-runs/TR-8762/folder/13176929/41237687/1247681388
Email or phone of affected tester (no customers): kiatest.78+ck3132610@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: iPhone 16/iOS 18.7.1
App Component: User Settings

Action Performed:

1. Launch Hybrid app
2. Create a new gmail account
3. On the onboarding, select Manage my team's expenses > 1-10 option
4. Select either Netsuite, Sage Intacct or QBD accounting software which upgrade to control WS
5. Tap Continue & finish onboarding
6. Go to Account >> Subscriptions >> Explore all plans button
7. Select Downgrade to Collect
8. Tap Downgrade Workspace or try tapping app back button

Expected Result:

User able to downgrade workspace to Collect in subscriptions page f he chooses Netsuite, QBD or Sage during onboarding

Actual Result:

App freezes on downgrade workspace page. User unable to downgrade workspace to Collect in subscriptions page f he chooses Netsuite, QBD or Sage during onboarding

Note: Issue happens for other locations too (UK, New Zealand, Australia) using a VPN service

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7102230_1773419715738.ScreenRecording_03-13-2026_12-23-28_1.1.mp4

View all open jobs on GitHub

[melvin-bot]

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

[OSBotify]

Investigation Summary

Classification: Frontend bug
Causing PR: #82764 - "Freeze non top screens to prevent extra-rerenders" by @VickyStash (High confidence)
Related Issues: None

Recommendation: REVERT

PR #82764 introduced aggressive screen freezing logic that freezes non-top screens in the navigation stack, including modal/RHP screens like the workspace downgrade page. The PR removes the isBelowFocused exception on mobile that previously prevented freezing the screen directly below the focused one. This is causing the app to freeze when users navigate to the downgrade workspace page on iOS.

Labels: No label changes needed - this is a frontend bug affecting iOS app, so DeployBlockerCash should remain.

Detailed Analysis

Evidence

• The issue is reproducible in staging but NOT in production, indicating it was introduced by a PR in the current staging deploy (9.3.37-0)
• PR Freeze non top screens to prevent extra-rerenders #82764 was merged on March 12, 2026 at 14:05:57Z and is included in this staging deploy (position 33 in chronological order)
• The bug was reported on March 13, 2026, shortly after the PR was merged
• The issue specifically mentions the app freezes on the downgrade workspace page on iOS

Verification

PR #82764 modified the following key files:

1. src/libs/Navigation/AppNavigator/createSplitNavigator/index.tsx - Added freezeNonTopScreens: true to the SplitNavigator
2. src/libs/Navigation/PlatformStackNavigation/createPlatformStackNavigatorComponent/ScreenFreezeWrapper.tsx - Created new screen freezing wrapper using react-freeze
3. patches/react-navigation/@react-navigation+native-stack+7.3.14+003+freeze-screen-below-focused.patch - Removed the isBelowFocused exception in native-stack that previously prevented freezing screens below the focused one on mobile

The patch changed:

// Before (did NOT freeze screen below focused on Fabric)
const shouldFreeze = isFabric() ? !isPreloaded && !isFocused && !isBelowFocused : !isPreloaded && !isFocused;

// After (DOES freeze screen below focused)
const shouldFreeze = !isPreloaded && !isFocused;

Root Cause

The downgrade workspace page is opened as a modal/RHP screen. With the new aggressive screen freezing logic, when this screen is rendered, the underlying screens are frozen using the react-freeze library. The ScreenFreezeWrapper wraps screen content and uses <Freeze freeze={frozen}> to freeze React trees.

On iOS specifically, when users navigate to the downgrade page after selecting NetSuite, Sage Intacct, or QBD during onboarding (which creates a Control workspace), the screen freezing logic is incorrectly freezing the downgrade page itself or causing a freeze state that prevents interaction.

The issue occurs specifically in the onboarding flow with accounting software because:

1. User creates account and selects accounting integration during onboarding
2. This upgrades workspace to "Control" plan
3. User navigates to Account > Subscriptions > Explore all plans > Downgrade to Collect
4. The downgrade page is rendered as a modal/RHP
5. The new screen freezing logic freezes the navigation stack incorrectly
6. App becomes unresponsive on iOS

[MelvinBot]

Proposal

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

The app freezes on the "downgrade workspace" page when a user who selected Netsuite, QBD, or Sage Intacct during onboarding (creating a Control workspace) tries to downgrade to Collect via Account > Subscriptions > Explore all plans > Downgrade to Collect. The freeze happens after tapping "Downgrade Workspace" or even the back button. The issue is iOS-only and reproducible in staging (9.3.37.0) but NOT in production.

What is the root cause of that problem?

The most likely culprit is PR #82764 ("Freeze non top screens to prevent extra-rerenders"), which was merged in the current staging deploy.

This PR patches @react-navigation/native-stack to remove a Fabric-specific safety guard. Before the patch, on iOS (which uses Fabric), the screen directly below the focused one was explicitly exempted from being frozen. The original code had this logic:

// BEFORE (safe):
const shouldFreeze = isFabric() ? !isPreloaded && !isFocused && !isBelowFocused : ...
// AFTER (aggressive):
const shouldFreeze = !isPreloaded && !isFocused;

The original Fabric exemption existed because "when screen is frozen, animated and reanimated values are not updated due to component being unmounted".

Here's how this causes the freeze in the downgrade flow:

1. User is on the Settings > Subscription page (inside SettingsSplitNavigator)
2. User opens ComparePlansModal (a ReanimatedModal with animations)
3. User taps "Downgrade to Collect" — this simultaneously closes the modal (fadeOut animation) and navigates to WORKSPACE_DOWNGRADE (RHP push) in the same synchronous call (SubscriptionPlanCardActionButton.tsx:59-76)
4. The RHP push makes SettingsSplitNavigator no longer the focused screen
5. With the new patch: shouldFreeze becomes true for the Settings screen. react-freeze then throws a never-resolving Promise via Suspense to suspend the entire Settings component tree
6. The ComparePlansModal's closing ReanimatedModal animation is still in progress when the freeze activates. Since "animated and reanimated values are not updated due to component being unmounted" (exactly the scenario the Fabric guard protected against), the animation hangs
7. The DelayedFreeze patch adds setTimeout(0) + requestAnimationFrame before freezing, but this timing window can still overlap with the modal transition on iOS

Additionally, the WorkspaceDowngradePage itself has 5+ Onyx collection-level subscriptions (policy, ownerPolicies, cardFeeds) that all re-evaluate when downgradeToTeam() fires its optimistic update changing policy.type. The component swaps between DowngradeIntro and DowngradeConfirmation, and DowngradeConfirmation adds yet another policy collection subscriber. This cascade of re-renders compounds with the freeze mechanism.

Key evidence:

• ScreenFreezeWrapper.tsx:16-17 contains a warning: "Decouple the Suspense render task so it won't be interrupted by React's concurrent mode and stuck in an infinite loop" — showing the PR authors were aware of this risk
• The ScreenFreezeWrapper mitigation only applies to web; on iOS, freeze behavior comes entirely from the patched NativeStackView
• The accounting connection (Netsuite/QBD/Sage) doesn't trigger any special blocked state, but these workspaces have larger policy objects making collection evaluations more expensive

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

Option A (quick fix — revert the Fabric guard removal): Restore the isBelowFocused exemption for Fabric in the @react-navigation/native-stack patch so the screen directly below the focused one is never frozen on iOS. This restores the behavior that was working in production:

In patches/react-navigation/@react-navigation+native-stack+7.3.14+003+freeze-screen-below-focused.patch, change:

const shouldFreeze = !isPreloaded && !isFocused;

back to:

const shouldFreeze = isFabric() ? !isPreloaded && !isFocused && !isBelowFocused : !isPreloaded && !isFocused;

Option B (targeted fix): Ensure the ComparePlansModal close animation completes before navigating. In SubscriptionPlanCardActionButton.tsx, use a callback/timeout to delay navigation until the modal close finishes, avoiding the race between the modal close animation and the screen freeze activation.

Option A is recommended as it addresses the root cause directly and restores the iOS safety behavior that was intentionally there.

What alternative solutions did you explore? (Optional)

• Investigated whether the freeze could be caused by Onyx subscription cascades in WorkspaceDowngradePage (5+ collection watchers re-evaluating when downgradeToTeam fires). While this contributes to render load, it doesn't explain why the issue is staging-only since this code hasn't changed.
• Investigated the lazy illustration loading system (useMemoizedLazyIllustrations) used by both DowngradeIntro and DowngradeConfirmation. No evidence of a freeze-inducing issue there.
• Checked if accounting connections (Netsuite/QBD/Sage) trigger a special blocked state — they do not. SubscriptionPlanDowngradeBlockedPage only activates for annual subscriptions with canDowngrade=false or invoicing subscriptions.

Relevant code references:

• src/pages/settings/Subscription/SubscriptionPlan/SubscriptionPlanCardActionButton.tsx:59-76 — simultaneous modal close + navigation
• src/pages/workspace/downgrade/WorkspaceDowngradePage.tsx:32-147 — downgrade page with heavy Onyx subscriptions
• patches/react-navigation/@react-navigation+native-stack+7.3.14+003+freeze-screen-below-focused.patch — the Fabric guard removal
• patches/react-native-screens/react-native-screens+4.15.4+001+delay-freeze-until-paint.patch — the delayed freeze timing
• src/libs/Navigation/PlatformStackNavigation/createPlatformStackNavigatorComponent/ScreenFreezeWrapper.tsx:16-17 — infinite loop warning

---

Next Steps for Contributor+ team: Reply with @MelvinBot implement this to create a draft PR, @MelvinBot <your feedback> to refine this analysis, or explain why you are rejecting Melvin's proposal.