Error: TaskQueue: Error with task : [Pusher] instance not found. Pusher.subscribe()

[sentry]

Sentry Issue: APP-29B

Error: TaskQueue: Error with task : [Pusher] instance not found. Pusher.subscribe()
            most likely has been called before Pusher.init()
  at InteractionManager.runAfterInteractions$argument_0 (src/libs/Pusher/index.native.ts:214:40)

Issue Owner

Current Issue Owner: @

[melvin-bot]

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

[melvin-bot]

Triggered auto assignment to @laurenreidexpensify (Bug), see https://stackoverflow.com/c/expensify/questions/14418 for more details. Please add this bug to a GH project, as outlined in the SO.

[melvin-bot]

📣 @sentry[bot]! 📣
Please report bugs or suggest features in the #expensify-open-source Slack channel, don't directly open issues in this repo!
Instructions here to join the channel 📖

[rlinoz]

Coming from https://expensify.slack.com/archives/C05LX9D6E07/p1770386477239199

@Krishna2323 is the one implementing this 😄

[twilight2294]

Proposal

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

The app crashes with the error [Pusher] instance not found. Pusher.subscribe() most likely has been called before Pusher.init() during normal usage, particularly when users sign out or when session cleanup occurs. This error is misleading because it's not actually caused by calling subscribe() before init().

What is the root cause of that problem?

The root cause is a race condition between Pusher.disconnect() and pending Pusher.subscribe() calls, introduced by the asynchronous InteractionManager.runAfterInteractions() deferral.

Here's the exact sequence:

1. Pusher.init() completes — The socket is initialized and initPromise resolves successfully (https://github.com/Expensify/App/blob/main/src/libs/Pusher/index.native.ts#L80).

2. Pusher.subscribe() is called (for example, by subscribeToUserEvents() or subscribeToReportTypingEvents()) — At line 207, the code awaits initPromise, which resolves immediately since init already completed. However, at line 211, the actual subscription logic is deferred via InteractionManager.runAfterInteractions() (https://github.com/Expensify/App/blob/main/src/libs/Pusher/index.native.ts#L207-L211).

3. Pusher.disconnect() is called BEFORE the deferred callback fires — This happens when a user signs out (https://github.com/Expensify/App/blob/main/src/libs/actions/Session/index.ts#L961-L976) or when AuthScreens unmounts (https://github.com/Expensify/App/blob/main/src/libs/Navigation/AppNavigator/AuthScreens.tsx#L347-L353). The disconnect() function sets socket = null at line 342 and replaces initPromise with a new never-resolved promise (https://github.com/Expensify/App/blob/main/src/libs/Pusher/index.native.ts#L335-L349).

4. The deferred callback fires — Now when the InteractionManager.runAfterInteractions() callback from step 2 finally executes, it finds socket === null (because disconnect() already ran) and throws the misleading error at lines 213-216 (https://github.com/Expensify/App/blob/main/src/libs/Pusher/index.native.ts#L213-L216).

The critical issue is that InteractionManager.runAfterInteractions() introduces a non-deterministic delay between when initPromise resolves and when the subscription logic actually runs. During this window, disconnect() can set socket = null, causing the guard to trigger even though subscribe() was correctly called after init().

The same bug exists in the web implementation at https://github.com/Expensify/App/blob/main/src/libs/Pusher/index.ts#L208-L211.

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

Instead of throwing an error when socket is null inside the runAfterInteractions callback, we should gracefully bail out. If disconnect() was called, the subscription is no longer needed anyway.

In src/libs/Pusher/index.native.ts, change lines 212-216:

InteractionManager.runAfterInteractions(() => {
    // If socket is null here, it means disconnect() was called after
    // initPromise resolved but before this deferred callback ran.
    // In that case, we should just bail out gracefully.
    if (!socket) {
        Log.info('[Pusher] subscribe() cancelled — socket was disconnected before interaction completed');
        resolve();
        return;
    }

In src/libs/Pusher/index.ts, make the identical change at lines 206-211:

https://github.com/Expensify/App/blob/main/src/libs/Pusher/index.ts#L208-L211

This fix is correct because:

• The guard was originally designed to prevent calling subscribe() before init(), but that's already impossible due to the initPromise gate
• The only way socket can be null inside initPromise.then(...) is if disconnect() was called during the runAfterInteractions delay
• After disconnect(), subscriptions are no longer relevant (user is signing out or session is being cleaned up)
• Using resolve() instead of reject() prevents spurious error logging

What alternative solutions did you explore?

An alternative would be to cancel pending InteractionManager tasks in disconnect(), but React Native's InteractionManager doesn't provide a reliable cancellation API for already-queued tasks. The graceful bailout approach is simpler and handles the race condition at the point where it manifests.