block refetching when reauthenticating after an error

[erquhart]

Bug

The websocket connection can quietly drop without recovery. This happens often when a native app is brought from background after token has expired, but can happen outside of this context as well.

Walkthrough

1. Once token authenticate succeeds, a refetch is scheduled for just before the new token expires.
2. Around the time of the scheduled refetch, the user initiates a query or mutation with the near-expired token.
3. The server finds the token to be expired and returns an auth error.
4. Reauthentication is attempted, which stops the websocket connection and fetches a new token.
5. In a race condition, the scheduled refetch runs at this point, rendering the still-running reauthentication attempt outdated.
6. The reauthentication attempt returns early due to being outdated, never restarts the connection (which would happen here).
7. The scheduled refetch resolves, but no authentication call can be made as the connection is stopped.
8. The scheduled refetch ends with a socket resume attempt, which does not work on stopped connections.

The socket remains closed. Authentication state is unchanged, client appears authenticated to the user.

Root cause

tryToReauthenticate() only runs in response to auth errors, refetchToken() is general purpose - for initialization and preemptive reauth. tryToReauthenticate() stops the connection and restarts at the end, refetchToken() does not. Both functions wait for token refetch and will bail if another token refetch (from either function) has started during the wait. If refetchToken() runs while tryToReauthenticate() is fetching, this bug occurs, as tryToReauthenticate() has stopped the connection and will bail before restarting, and refetchToken() does not restart the connection (nor should it).

This solution

This solution blocks any calls to refetchToken() from running if tryToReauthenticate() has started and has not yet succeeded.

Other solutions considered

We could schedule refetches sooner to help close the race condition gap here, but there's still no guarantee it won't occur. The chosen solution seemed closer to root cause.

[erquhart]

Each solution attempt here has complicated the auth/connect state machines and introduced new issues. I've also found a historical root cause that may inform the path forward. Moved findings to #22 for futher discussion.