[$250] Fix doubled OpenApp on delegate (copilot) account switch

[MelvinBot]

When a user switches into a copilot/delegate account via the account switcher, OpenApp fires twice — the first call resolves with skeletons visible, then a second OpenApp runs while skeletons are still visible, causing a noticeable double-loading experience on large accounts.

Two independent root causes:

1. NetworkState reconfigure path: The CONNECT_AS_DELEGATE response updates SESSION.accountID. The SESSION subscriber in NetworkState.ts calls configureAndSubscribe() to rebuild the NetInfo subscription. Re-subscribing emits a synthetic null → true transition that the listener treats as a network recovery event → reconnect() → openApp().

2. DelegateAccessHandler recovery effect path: Onyx.clear(KEYS_TO_PRESERVE_DELEGATE_ACCESS) preserves HAS_LOADED_APP=true but not IS_LOADING_APP. After the clear, the state is briefly hasLoadedApp=true && isLoadingApp=undefined — exactly the trigger for the recovery effect, which fires its own openApp().

Related PR: #89254

Issue Owner

Current Issue Owner: @abzokhattab

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022049837260593240936
• Upwork Job ID: 2049837260593240936
• Last Price Increase: 2026-04-30

[MelvinBot]

Proposal

What is the root cause of that problem?

When switching to a copilot/delegate account, OpenApp fires twice because two independent code paths each trigger their own openApp() call:

Root Cause 1 — NetworkState reconfigure path: The CONNECT_AS_DELEGATE response updates SESSION.accountID. The SESSION subscriber in NetworkState.ts:332-342 detects the accountID change and calls configureAndSubscribe(), which tears down and recreates the NetInfo subscription (NetworkState.ts:270-323). The new subscription emits a synthetic state event. If prevIsInternetReachable is null (set by setForceOffline at line 159), the listener at line 317 treats this as a network recovery → onReachabilityRestored() → notifyReconnectListeners() → Reconnect.ts:58-60 → openApp().

Root Cause 2 — DelegateAccessHandler recovery effect: Onyx.clear(KEYS_TO_PRESERVE_DELEGATE_ACCESS) preserves HAS_LOADED_APP (Delegate.ts:30) but does not preserve IS_LOADING_APP (Delegate.ts:23-42). After the clear, the state is hasLoadedApp=true && isLoadingApp=undefined — exactly the trigger for the recovery effect in DelegateAccessHandler.tsx:61-73, which fires its own openApp().

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

Both root causes need to be addressed:

1. For Root Cause 2: Introduce a clearOnyxForDelegateTransition() helper in Delegate.ts that merges IS_LOADING_APP=true before calling Onyx.clear(), and adds IS_LOADING_APP to the preserve list. This ensures post-clear state is always isLoadingApp=true, preventing the recovery effect from firing. Replace all 4 existing Onyx.clear(KEYS_TO_PRESERVE_DELEGATE_ACCESS) call sites (3 in Delegate.ts, 1 in Session/index.ts) with this helper.

2. For Root Cause 1: Add a suppression flag in NetworkState.ts that skips the next onReachabilityRestored() call when configureAndSubscribe() is invoked due to a SESSION accountID change. This prevents the synthetic NetInfo transition from being misinterpreted as a network recovery event.

PR #89254 already implements both of these fixes.

---

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.

[melvin-bot]

Current assignee @abzokhattab is eligible for the External assigner, not assigning anyone new.

[melvin-bot]

Job added to Upwork: https://www.upwork.com/jobs/~022049837260593240936

[Yatin-Bhatti]

Proposal

What is the root cause of that problem?

The redundant OpenApp execution is caused by a Sessional Lifecycle Desynchronization during the account-switching phase.
Currently, the application treats the "Delegate Switch" as two fragmented operations: a data-clear and a network-reconfiguration. This creates two distinct "False Positive" triggers:
The Incomplete State Trigger: Onyx.clear preserves the "App Loaded" status but resets the "Is Loading" status. This creates an illegal state where the app thinks it is fully initialized but lacks the "Loading" gate, causing the DelegateAccessHandler to "panic" and trigger a recovery OpenApp.
The Synthetic Network Event: Re-configuring the NetworkState due to an account change forces a NetInfo re-subscription. This re-subscription emits a "synthetic" connection event that the system misinterprets as a transition from "Offline" to "Online," triggering a second, redundant openApp.
The system lacks a Transition Lock to signal that these state changes are part of a deliberate account handover rather than a system failure or network recovery.

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

I propose an Atomic Sessional Handover approach to silence redundant triggers at the source:

1. Implement a Transition Middleware: I will create a unified transitionToDelegateAccount utility. This middleware will ensure that IS_LOADING_APP is programmatically locked to true before the Onyx.clear operation begins. By ensuring IS_LOADING_APP is in the "Preserve List," we prevent the DelegateAccessHandler from ever seeing the indeterminate state that triggers the first redundant call.

2. Context-Aware Network Suppression: Instead of adding flags to the network listener, I will update NetworkState.ts to implement a "Quiescent Subscription" model. When the account ID changes, the logic will perform a "Silent Re-subscription" that explicitly ignores the first emitted event if the network status has not physically changed.

3. Synchronize the Reset Lifecycle: I will refactor the transition flow to ensure that the navigation to the new account's home screen and the final data hydration are part of a single, orchestrated sequence. This ensures the "Skeletons" are only replaced once the final OpenApp call (the legitimate one) has successfully returned.

4. Logic Centralization: This fix removes the need for "Suppression Flags" inside UI components, moving the responsibility for sessional stability to the logic layer where the switch is initiated.

What alternative solutions did you explore? (Optional)

I considered the approach of simply adding IS_LOADING_APP to the existing clear list. However, I rejected this as an incomplete solution because it doesn't address the Synthetic Network Recovery bug. I also explored Proposal 1's idea of a suppression flag in NetworkState, but determined that a "Quiescent Subscription" is more robust because it relies on data-identity (checking if the network state actually changed) rather than a manually managed boolean flag, which is less prone to race conditions.

[CyberMechAV]

Proposal

I can fix this double OpenApp loading issue.

I understand the two separate triggers:

NetworkState.ts rebuilds the NetInfo subscription after CONNECT_AS_DELEGATE updates SESSION.accountID. The new subscription emits a synthetic connectivity transition, which is incorrectly treated as recovery and calls reconnect() -> openApp().

DelegateAccessHandler clears Onyx while preserving HAS_LOADED_APP, but IS_LOADING_APP is briefly undefined. That creates hasLoadedApp=true && isLoadingApp=undefined, which triggers the recovery effect and fires another openApp().

My fix would be focused and minimal:

Guard the NetInfo reconfigure path so synthetic initial emissions after resubscribe do not trigger reconnect/openApp.

Preserve or explicitly stabilize IS_LOADING_APP during delegate Onyx.clear(), or adjust the recovery effect so it does not run during intentional delegate account switching.

Add/update tests around delegate account switching to prove OpenApp only fires once.

Verify against the behavior from related PR #89254 and make sure the skeleton state does not restart for large accounts.

I can inspect the existing implementation, patch both paths, and provide a clean PR with the exact reasoning and test coverage.