fix(sdk): re-emit reset on SDK reconnect so Meteor's onReconnect runs

Meteor's accounts-base registers a per-call DDP.onReconnect handler in
callLoginMethod (accounts_client.js:292) that retries login with the
latest stored token and calls makeClientLoggedOut on failure. With our
stub keeping Meteor's connection permanently 'connected', that handler
never fires when the underlying SDK socket reconnects, so server-side
force-logouts (resetUserE2EKey → ws.terminate) leave the user with stale
credentials and no automatic recovery.

Listen for the SDK's 'connected' event in stubMeteorStream and fire
'reset' on every subsequent reconnect — Meteor's _streamHandlers.onReset
then drives _callOnReconnectAndSendAppropriateOutstandingMethods, which
in turn invokes the onReconnect callback. That covers both branches:
  - if localStorage was rotated by a concurrent flow, the resume retry
    succeeds and setUserId fires;
  - if the token is genuinely stale, the resume retry fails and Meteor's
    own makeClientLoggedOut clears creds and routes to /login.

Now that Meteor's flow handles the recovery, simplify the
sdk.account.loginWithToken wrap to just swallow the auth-error
rejection (so DDPSDK's `void` auto-relogin doesn't surface as an
unhandled rejection / pageError) — no more deferred cleanup, no
retry-through-Meteor duplication.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Author: ggazzo

apps/meteor/client/lib/sdk/ddpSdk.ts

@@ -135,21 +135,6 @@ export const ensureConnectedAndAuthenticated = async (): Promise<void> => {
 	}
 };
 
-const forceClientLoggedOut = (sdk: DDPSDK): void => {
-	try {
-		Accounts._unstoreLoginToken();
-	} catch {
-		// ignore
-	}
-	try {
-		(Meteor.connection as unknown as { setUserId: (uid: string | null) => void }).setUserId(null);
-	} catch {
-		// ignore
-	}
-	sdk.account.uid = undefined;
-	sdk.account.user = undefined;
-};
-
 const isAuthError = (error: unknown): boolean => {
 	if (!error || typeof error !== 'object') return false;
 	const e = error as { error?: unknown; reason?: unknown };
@@ -236,65 +221,26 @@ if (typeof window !== 'undefined') {
 	//    (nothing rotated it mid-flight) AND
 	//  - the SDK account didn't get refreshed by a successful adopt while
 	//    we were awaiting (sdk.account.uid still maps to this token's user)
+	// Wrap account.loginWithToken so the SDK's auto-relogin rejection (called
+	// with `void` in DDPSDK.create) doesn't surface as an unhandled rejection
+	// (window.onunhandledrejection → pageError). The actual recovery from a
+	// failed auto-relogin is now driven by Meteor's `DDP.onReconnect`
+	// callback (registered by `callLoginMethod`), which fires after
+	// stubMeteorStream re-emits `reset` on each SDK 'connected' event. That
+	// callback retries login with the latest stored token and calls
+	// `makeClientLoggedOut` on failure — no need to duplicate that logic.
 	const account = sdk.account as unknown as { loginWithToken: (token: string) => Promise<unknown> };
 	const originalLogin = account.loginWithToken.bind(sdk.account);
 	account.loginWithToken = async (token: string) => {
-		const triedWithUid = sdk.account.uid;
 		try {
 			return await originalLogin(token);
 		} catch (error) {
-			if (!isAuthError(error)) throw error;
-			// Defer the recovery so a concurrent fresh login (e.g. SAML's
-			// post-redirect resume, password login from the form) has a chance
-			// to rotate the stored token and SDK account state. After the
-			// delay, if state is still stuck on the same token+uid we tried
-			// with, retry the login through Meteor with whatever's currently
-			// in localStorage. Two outcomes:
-			//   - if localStorage was rotated by a concurrent flow (or a test's
-			//     loginByUserState re-added the same token to mongo via
-			//     $addToSet AFTER the server's unsetLoginTokens), the retry
-			//     hits Meteor's normal success path and setUserId fires;
-			//   - if the token is still genuinely stale (real force-logout, no
-			//     concurrent recovery), Meteor's login callback receives the
-			//     auth error and we call makeClientLoggedOut to drive the user
-			//     to /login.
-			// This avoids the race where _pollStoredLoginToken short-circuits
-			// because the stored token didn't visibly change, but the
-			// underlying mongo token was wiped+re-added.
-			setTimeout(() => {
-				const stillSameStored = readStoredLoginToken() === token;
-				const accountStillReflectsThisToken = sdk.account.uid === triedWithUid;
-				console.warn('[ddpSdk] auth-error cleanup tick', {
-					stillSameStored,
-					accountStillReflectsThisToken,
-					triedWithUid,
-					currentUid: sdk.account.uid,
-				});
-				if (!stillSameStored || !accountStillReflectsThisToken) return;
-				const currentToken = readStoredLoginToken();
-				if (!currentToken) {
-					console.warn('[ddpSdk] auth-error: no stored token, forcing logout');
-					forceClientLoggedOut(sdk);
-					return;
-				}
-				console.warn('[ddpSdk] auth-error: retrying Meteor.loginWithToken');
-				try {
-					(Meteor as unknown as { loginWithToken: (token: string, cb: (err: unknown) => void) => void }).loginWithToken(
-						currentToken,
-						(err) => {
-							if (err) {
-								console.warn('[ddpSdk] retry Meteor.loginWithToken rejected', err);
-								forceClientLoggedOut(sdk);
-							} else {
-								console.warn('[ddpSdk] retry Meteor.loginWithToken succeeded');
-							}
-						},
-					);
-				} catch (e) {
-					console.warn('[ddpSdk] retry Meteor.loginWithToken threw', e);
-					forceClientLoggedOut(sdk);
-				}
-			}, 500);
+			if (isAuthError(error)) {
+				// Meteor's onReconnect path will retry through stubMeteorStream
+				// with the current localStorage token; nothing for us to do here
+				// beyond not letting the rejection escape.
+				return undefined;
+			}
 			throw error;
 		}
 	};

apps/meteor/client/meteor/overrides/stubMeteorStream.ts

@@ -211,3 +211,30 @@ queueMicrotask(() => {
 		console.warn('[stubMeteorStream] failed to bootstrap connected state', err);
 	}
 });
+
+// When the underlying SDK socket reconnects (e.g. after a server-side
+// ws.terminate from force-logout in microservices), Meteor's connection sees
+// no transport event because the stub keeps reporting 'connected'. As a
+// result, Meteor's normal reconnect machinery — `_streamHandlers.onReset` →
+// `_callOnReconnectAndSendAppropriateOutstandingMethods` → DDP.onReconnect
+// callbacks → the per-call `_reconnectStopper` that retries login with the
+// latest stored token (and calls `makeClientLoggedOut` on failure) — never
+// fires. The user is left with stale credentials.
+//
+// Fire `reset` on every subsequent SDK 'connected' event so accounts-base's
+// onReconnect callback retries login with whatever's currently in
+// localStorage. The first connect is handled by the queueMicrotask above;
+// skip it here.
+const sdk = getDdpSdk();
+let firstConnectHandled = false;
+sdk.connection.on('connected', () => {
+	if (!firstConnectHandled) {
+		firstConnectHandled = true;
+		return;
+	}
+	try {
+		fire('reset');
+	} catch (err) {
+		console.warn('[stubMeteorStream] reset on SDK reconnect failed', err);
+	}
+});