fix(sdk): only bridge result/updated frames when Meteor still has the invoker

After force-logout cycles (e.g. resetUserE2EKey → ws.terminate → SDK
reconnect), stale result/updated frames for methods whose Meteor invoker
already cleared can arrive over the SDK socket. _process_updated then
throws "No callback invoker for method N" out of an async generator —
the throw escapes the bridge's try/catch as an unhandled rejection and
aborts Meteor's frame queue, so subsequent login result frames never
land and the page stays wedged on /login.

Gate the result/updated bridge on _methodInvokers[id] existing so stale
frames are silently dropped instead of corrupting Meteor's frame
processing.

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

Author: ggazzo

apps/meteor/client/meteor/overrides/ddpSdkCollectionBridge.ts

@@ -39,6 +39,12 @@ const SUBSCRIPTION_LIFECYCLE_FRAMES = new Set(['ready', 'nosub']);
 // bridge so SDK's own callAsync flows aren't surfaced into Meteor.
 const isSdkInternalId = (id: unknown): boolean => typeof id === 'string' && id.startsWith('rc-ddp-client-');
 
+const getMeteorMethodInvokers = (): Record<string, unknown> => {
+	return (Meteor.connection as unknown as { _methodInvokers?: Record<string, unknown> })._methodInvokers ?? {};
+};
+
+const meteorHasInvoker = (id: unknown): boolean => typeof id === 'string' && id in getMeteorMethodInvokers();
+
 const shouldBridgeToMeteor = (frame: ParsedDdpFrame): boolean => {
 	if (!frame || typeof frame.msg !== 'string') return false;
 
@@ -47,15 +53,29 @@ const shouldBridgeToMeteor = (frame: ParsedDdpFrame): boolean => {
 	}
 
 	if (frame.msg === 'result') {
-		return !isSdkInternalId(frame.id);
+		if (isSdkInternalId(frame.id)) return false;
+		// Drop result frames whose Meteor invoker is gone — feeding them
+		// surfaces as "Received method result but no methods outstanding" and
+		// can race with `updated` to leave Meteor's _processOneDataMessage in a
+		// half-processed state (force-logout cycles invalidate the in-flight
+		// method's invoker before its result returns over the SDK socket).
+		return meteorHasInvoker(frame.id);
 	}
 	if (frame.msg === 'updated') {
 		const methods = Array.isArray(frame.methods) ? (frame.methods as unknown[]) : [];
+		if (methods.length === 0) return false;
 		// If any of the methodIds in the `updated` frame is SDK-internal, drop
 		// the whole frame: Meteor processes every id and would throw on the
 		// first miss. In practice an `updated` frame carries ids from a single
 		// originating method call, so this is all-or-nothing anyway.
-		return methods.length > 0 && !methods.some(isSdkInternalId);
+		if (methods.some(isSdkInternalId)) return false;
+		// Same defence as for `result` — bridge only when Meteor still has an
+		// invoker for every methodId. Without this, `_process_updated` throws
+		// "No callback invoker for method N" out of an async generator and the
+		// throw escapes the try/catch below as an unhandled rejection,
+		// aborting Meteor's frame queue (the next login's result never lands,
+		// userId stays null, and the page is stuck on /login).
+		return methods.every(meteorHasInvoker);
 	}
 
 	return false;