Sign-out sweep: serial retry-armed instance logouts stall the CM logout, a failed logout leaves basic-auth on disk, and a re-added entity is skipped

[dawsontoth]

Summary

authStore.signOutFromPotentiallyAuthenticatedInstances (src/features/auth/store/authStore.ts) is the per-entity sweep that Studio's Sign out runs before the central-manager /Logout/. Three defects in it were surfaced by the cross-model review of the #1672 fix and are pre-existing, so they were left out of that PR. None is introduced by the fix; all three are still present after it.

1. Instance logouts are serial, retry-armed, and ahead of the central-manager logout

The loop awaits onInstanceLogoutSubmit once per entity, in order, and only then does useLogout post /Logout/ to the central manager and run logoutOnSuccess (which is what clears localStorage). Every client it uses comes from getInstanceClient, which installs curryRetryGatewayErrors: on a 502/503/504 that interceptor sleeps 5s + 10s + 20s before giving up (src/integrations/api/retryGatewayErrors.ts), and a hung connection burns the client's 60s timeout.

Two signed-in instances, the first answering 503 on operation: 'logout': the second instance's session, the central-manager logout, and the storage wipe all wait ~35s. A user who clicks Sign out and walks away is still fully signed in for that window.

Suggested shape: run the local clears for every entity up front (they already precede each network call), then dispatch the instance logouts with Promise.allSettled and don't make the central-manager logout wait on them — or at least build the logout client without the gateway-retry interceptor.

2. A failed instance logout leaves stored basic-auth credentials on disk

flagForBasicAuth(id, null) and flagForFabricConnect(id, false) run only after a successful POST, inside onInstanceLogoutSubmit (src/integrations/api/instance/auth/onInstanceLogoutSubmit.ts). The sweep's own clears don't touch them — unlike signOutLocally, which does. Normally logoutOnSuccess → clearLocalStorage wipes them anyway, so this only bites when the instance logout fails and the central-manager /Logout/ rejects (offline, 401): then Studio:BasicAuth:<id> (base64 username/password) survives a user-requested sign-out until the next successful logout.

Suggested shape: clear the basic-auth entry and the Fabric Connect flag in the sweep's local-clear block, the way signOutLocally already does, so a failed POST cannot leave them behind.

3. An entity re-added during an await is skipped

The loop is a for…in over potentiallyAuthenticated with an await between iterations, and signOutAllLocally snapshots Object.keys first for exactly this reason. A loadUser in flight when the sweep starts captured its key before the clear, and its flagKeyAsSignedIn on resolve re-adds potentiallyAuthenticated[id]; keys added after a for…in starts are not visited, so the sweep never revisits it, and logoutOnSuccess's localStorage.clear() does not touch the in-memory entry. A same-tab re-login then inherits the prior user's connection — the leak signOutAllLocally was written to close. (Deleting the current key mid-loop is spec-safe; the re-add is the defect.)

Suggested shape: iterate a snapshot of the keys, and drop any entry re-added during the sweep at the end.

Notes

• Found by review, not by a customer report; no production trail beyond the [RUM] The instance-logout catch that exists to swallow a failure console.errors it straight into Error Tracking (34 events, 13 sessions, 30d) #1672 RUM family.
• All three are independent of the ordering fix in the [RUM] The instance-logout catch that exists to swallow a failure console.errors it straight into Error Tracking (34 events, 13 sessions, 30d) #1672 PR and can land separately.

[dawsontoth]

One more pre-existing finding from the same review cycle, same method, filed here rather than in the #1672 PR:

4. An in-flight Fabric Connect establish re-writes auth state after sign-out

resolveFabricConnectAuth sets fabricConnectAuth and calls flagForFabricConnect(id, true) / setUserForIdAndKey(id, …) when its proxy round-trip resolves, with no generation or "still signed in" check. If an instance page's establishFabricConnectAuth is awaiting the proxy when the user hits Sign out, the sweep clears everything and then the establish resolves and re-writes Studio:PotentiallyAuthenticated, re-sets Studio:FabricConnect:<id>, and re-installs a live JWT in memory for the user who just signed out. updateDirectOperationToken already has exactly this guard (it only writes when the entity is still in direct mode); the establish path does not.

Suggested shape: a sign-out generation counter (or reuse the explorer auth epoch) captured at the start of resolveFabricConnectAuth and checked before each write, the way updateDirectOperationToken checks mode.

[dawsontoth]

Status after #1680:

• Items 1 (serial, retry-armed logouts) and 2 (basic-auth / Fabric Connect flags left on a failed logout) are addressed by fix(auth): send the sign-out logout to the instance, and stop its failure reaching Error Tracking #1680 — the sweep now captures each logout client first, clears everything local through signOutLocally, and runs the logouts in parallel with a 10s timeout and no gateway-retry interceptor. Leaving this issue open for items 3 and 4.

5. Concurrent sign-outs are not coalesced

useLogoutMutation (src/features/auth/hooks/useLogout.ts) has no in-flight guard and the navbar calls mutate without checking isPending. A double-click runs the sweep twice: the second invocation sees an already-drained potentiallyAuthenticated and posts the central-manager /Logout/ while the first invocation's proxy-mode instance logouts are still in flight, so the CM tears down the session cookie those requests authenticate with, they 401, and the instance-side sessions survive.

Suggested shape: disable the Sign out control while the mutation is pending, or dedupe the sweep behind one shared promise the way establishFabricConnectAuth already does per id.