RocketChat/Rocket.Chat · warning

[stubMeteorStream] reset on SDK reconnect failed

Error message

[stubMeteorStream] reset on SDK reconnect failed

What it means

In the SDK-bridged client, a stub replaces Meteor's own DDP socket. On every SDK 'connected' event after the first, the stub fires a synthetic transport 'reset' so Meteor's connection machinery re-sends outstanding methods and retries login (via _streamHandlers.onReset and the DDP reconnect hooks). fire('reset') calls into Meteor internals and any handlers they invoke; if one of those throws, the exception is caught here and logged as '[stubMeteorStream] reset on SDK reconnect failed'. The reconnect itself already succeeded - the warning means the post-reconnect recovery pass did not fully run.

Source

Thrown at apps/meteor/client/meteor/overrides/stubMeteorStream.ts:222

	// callbacks → the _reconnectStopper that retries login with the latest
	// stored token and calls makeClientLoggedOut on failure (so the
	// account-manage-devices / admin-device-management / e2ee-key-reset
	// force-logout tests recover). The first connect is handled by the
	// queueMicrotask above; skip it here. The "method result but no methods
	// outstanding" / "No callback invoker" warnings the resent blocks
	// occasionally generate are caught by the bridge's async catch in
	// ddpSdkCollectionBridge.
	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);
		}
	});

	// Belt-and-suspenders: when the underlying SDK socket disconnects, also reset
	// `Accounts._lastLoginTokenWhenPolled` so the next `_pollStoredLoginToken`
	// (whether triggered by the 3s polling timer or an external poke like a test's
	// `loginByUserState`) is forced to compare against `null` and fire a fresh
	// login if the stored token still exists. This covers the gap where neither
	// `useForceLogout` (stream message lost in the broker race) nor
	// `_reconnectStopper`'s `makeClientLoggedOut` ran — without this, a stored
	// token equal to the cached `_lastLoginTokenWhenPolled` short-circuits the
	// poller and the user sits with stale credentials until the next genuine
	// token rotation.
	// Belt-and-suspenders for the EE force-logout path. The existing recovery
	// mechanisms (useForceLogout via stream message; _reconnectStopper via
	// fire('reset') calling makeClientLoggedOut on auth failure) BOTH clear
	// _lastLoginTokenWhenPolled when they run, but in microservices the
	// notify-user/<uid>/force_logout stream traverses

View on GitHub (pinned to b2c16d5842)

Solutions

1. Inspect the err logged after the message - it identifies the throwing handler
2. Force a clean re-alignment of Meteor and SDK session state: log out and log in again (fresh loginWithToken pass)
3. Reload the page as the blunt recovery if the UI looks wedged (e.g. stuck on PageLoading or stale credentials after force-logout)
4. Maintainers: harden individual reset handlers so one bad handler cannot fail the whole reset pass

When it happens

Trigger: Server closes the websocket (e.g. force-logout under microservices/ddp-streamer) and, on reconnect, a Meteor-side reset/reconnect handler throws; pending method callbacks referencing missing invokers during the resend; tests that replace Accounts internals so a reset handler meets unexpected state.

Common situations: Flaky networks during development where reconnect-resend hits half-finished client state; microservices deployments terminating sockets server-side; e2e tests stubbing parts of accounts-base.

Related errors

• [Message Delivery] High delay detected: ${receiveDelay}ms. P
• [accounts] changeStorageBackend failed
• Room not found
• error-invalid-user
• error-invalid-user

AI-assisted analysis of RocketChat/Rocket.Chat@b2c16d5842 (2026-08-18). Data as JSON: /api/errors/e24358b59138fdff. Report an issue: GitHub.