fix(sdk): gate transport overrides in-place to preserve boot timing

The previous gate moved the 5 SDK-transport overrides out of `overrides/index.ts`
into a dynamically imported `sdkTransport.ts`, and chained `meteor/login` after
its resolution. That changed two things at boot relative to the parent commit:

  - the override side effects (Meteor.connection wraps, _stream stub, queue
    drains) ran one microtask later than ddpSdk.ts and the always-on overrides
  - meteor/login was deferred until the dynamic chunk fetched

The shift was enough to flake every UI shard (logout flows, avatar upload,
admin rooms, settings reset, file upload, message edit, etc.) because the
post-relogin and bootstrap subscriptions raced the wraps that they depend on.

Restore the parent commit's exact boot order: `overrides/index.ts` imports the
5 SDK-transport modules synchronously again. The runtime gate moves *inside*
each module — `if (isSdkTransportEnabled()) { ... }` around the module's body —
so with the flag off the wraps don't apply, and with the flag on the timing is
identical to develop.

Drop `overrides/sdkTransport.ts` (no longer needed) and revert main.ts to the
parent's chain (no `sdkTransportReady` prepend). The boot banner moves to the
gated side-effect block in `ddpSdk.ts`.

Author: ggazzo

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

@@ -202,6 +202,11 @@ declare global {
 }
 
 if (typeof window !== 'undefined' && isSdkTransportEnabled()) {
+	// eslint-disable-next-line no-console
+	console.info(
+		'%c[Rocket.Chat] SDK-over-DDP transport enabled (experimental)',
+		'color:#fff;background:#f5455c;padding:2px 6px;border-radius:3px;font-weight:bold',
+	);
 	const sdk = getDdpSdk();
 	window.__rocketChatSdk = sdk;
 

apps/meteor/client/main.ts

@@ -2,27 +2,8 @@ import './meteor/overrides';
 import './meteor/startup';
 import './lib/sdk/ddpSdk';
 import './serviceWorker';
-import { isSdkTransportEnabled } from './lib/sdk/sdkTransportEnabled';
 
-// Defer the rest of the boot chain until the SDK-transport overrides are
-// actually installed (when the flag is on). They mutate
-// `Meteor.connection._send`, `_subscribe`, and `_stream` at module init —
-// loading them in parallel with `./meteor/login` would race the first
-// `Meteor.loginWithToken` call against the wrap, leaving the login frame on
-// the un-wrapped transport. With the flag off, the conditional resolves to a
-// resolved Promise immediately.
-const sdkTransportEnabled = isSdkTransportEnabled();
-if (sdkTransportEnabled) {
-	// eslint-disable-next-line no-console
-	console.info(
-		'%c[Rocket.Chat] SDK-over-DDP transport enabled (experimental)',
-		'color:#fff;background:#f5455c;padding:2px 6px;border-radius:3px;font-weight:bold',
-	);
-}
-const sdkTransportReady = sdkTransportEnabled ? import('./meteor/overrides/sdkTransport') : Promise.resolve();
-
-void sdkTransportReady
-	.then(() => import('./meteor/login'))
+import('./meteor/login')
 	.then(() => import('./importPackages'))
 	.then(() => import('./startup'))
 	.then(() =>

apps/meteor/client/meteor/overrides/ddpOverREST.ts

@@ -2,6 +2,7 @@ import { DDPCommon } from 'meteor/ddp-common';
 import { Meteor } from 'meteor/meteor';
 
 import { sdk } from '../../../app/utils/client/lib/SDKClient';
+import { isSdkTransportEnabled } from '../../lib/sdk/sdkTransportEnabled';
 import { getUserId } from '../../lib/user';
 
 const bypassMethods: string[] = ['setUserStatus', 'logout'];
@@ -128,4 +129,6 @@ const withDDPOverREST = (_send: (this: Meteor.IMeteorConnection, message: Meteor
 	};
 };
 
-Meteor.connection._send = withDDPOverREST(Meteor.connection._send);
+if (isSdkTransportEnabled()) {
+	Meteor.connection._send = withDDPOverREST(Meteor.connection._send);
+}

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

@@ -2,6 +2,7 @@ import { DDPCommon } from 'meteor/ddp-common';
 import { Meteor } from 'meteor/meteor';
 
 import { getDdpSdk } from '../../lib/sdk/ddpSdk';
+import { isSdkTransportEnabled } from '../../lib/sdk/sdkTransportEnabled';
 
 /**
  * Bridge incoming DDPSDK frames into Meteor.connection's collection dispatch.
@@ -93,4 +94,6 @@ export const installDdpSdkCollectionBridge = (): void => {
 	});
 };
 
-installDdpSdkCollectionBridge();
+if (isSdkTransportEnabled()) {
+	installDdpSdkCollectionBridge();
+}

apps/meteor/client/meteor/overrides/index.ts

@@ -1,7 +1,8 @@
-// Always-on Meteor patches that aren't tied to the DDP transport choice.
-// The 5 SDK-transport overrides (ddpOverREST, killMeteorStream, subscribeViaSDK,
-// stubMeteorStream, ddpSdkCollectionBridge) live in `./sdkTransport.ts` and
-// are loaded conditionally from main.ts via `isSdkTransportEnabled()`.
+import './ddpOverREST';
+import './ddpSdkCollectionBridge';
+import './subscribeViaSDK';
+import './stubMeteorStream';
+import './killMeteorStream';
 import './desktopInjection';
 import './oauthRedirectUri';
 import './settings';

apps/meteor/client/meteor/overrides/killMeteorStream.ts

@@ -1,6 +1,7 @@
 import { Accounts } from 'meteor/accounts-base';
 import { Meteor } from 'meteor/meteor';
 
+import { isSdkTransportEnabled } from '../../lib/sdk/sdkTransportEnabled';
 import { userIdStore } from '../../lib/user';
 
 /**
@@ -27,84 +28,33 @@ import { userIdStore } from '../../lib/user';
  * Meteor's WS now stays connected — invokers reach `_send`, which
  * ddpOverREST intercepts and routes to REST (or DDPSDK for `login`).
  */
-const conn = Meteor.connection as unknown as {
-	_subsBeingRevived: Record<string, unknown>;
-	_methodsBlockingQuiescence: Record<string, unknown>;
-	_messagesBufferedUntilQuiescence: unknown[];
-	_outstandingMethodBlocks: unknown[];
-	_methodInvokers: Record<string, unknown>;
-};
+if (isSdkTransportEnabled()) {
+	const conn = Meteor.connection as unknown as {
+		_subsBeingRevived: Record<string, unknown>;
+		_methodsBlockingQuiescence: Record<string, unknown>;
+		_messagesBufferedUntilQuiescence: unknown[];
+		_outstandingMethodBlocks: unknown[];
+		_methodInvokers: Record<string, unknown>;
+	};
 
-conn._subsBeingRevived = Object.create(null);
-conn._methodsBlockingQuiescence = Object.create(null);
-conn._messagesBufferedUntilQuiescence = [];
-
-/**
- * Force-clear Accounts._loggingIn once a uid lands in userIdStore.
- *
- * Meteor's loggedInAndDataReadyCallback flips _loggingIn back to false
- * from inside a Tracker.autorun that awaits Meteor.userAsync(). Our
- * findOneAsync await boundary breaks Tracker dep propagation, and the
- * same autorun is where Accounts.onLogin would normally fire — so
- * neither hook fires when synchronizeUserData later writes the user
- * into the store, and the UI stays on "Connecting..." with
- * Meteor.loggingIn() pinned to true.
- *
- * userIdStore is updated by the userAndUsers Tracker.autorun the moment
- * Accounts.connection.userId() flips, which happens inside
- * makeClientLoggedIn before the broken autorun is even installed. So
- * subscribing here gives a reliable "login completed" signal — just
- * skip the synchronous boot snapshot and react only to subsequent
- * transitions.
- */
-let saw: string | undefined = userIdStore.getState();
-userIdStore.subscribe((next) => {
-	if (next === saw) return;
-	saw = next;
-	if (next) {
-		(Accounts as unknown as { _setLoggingIn?: (v: boolean) => void })._setLoggingIn?.(false);
-	}
-});
-
-/**
- * Drain Meteor's outstanding-method queue on logout.
- *
- * Accounts.logout's `applyAsync` resolves immediately via Meteor's
- * fire-and-forget client path (the actual server response is awaited
- * only by the MethodInvoker callback). Inside that resolved `.then`,
- * makeClientLoggedOut clears userId, which fires our userIdStore
- * subscriber to teardown DDPSDK. By the time the server's logout result
- * frame would arrive, the DDPSDK socket is already closed — so the
- * logout MethodInvoker stays in `_outstandingMethodBlocks` with
- * `sentMessage=true` forever.
- *
- * The next `_addOutstandingMethod` call (e.g. token-resume right after
- * logout) checks `_outstandingMethodBlocks.length === 1` to decide
- * whether to send immediately. With the orphaned logout block ahead of
- * it, the new method is silently queued and never sent. Visible
- * failure: re-login after logout never produces a login `_send` and the
- * UI hangs on PageLoading.
- *
- * Drain inside Accounts.onLogout because it fires synchronously from
- * makeClientLoggedOut *before* setUserId(null) and before any
- * subsequent applyAsync can enqueue. Doing the same drain on the
- * userIdStore transition would race the test's `_pollStoredLoginToken`
- * call, which can enqueue the new login between makeClientLoggedOut and
- * Tracker's deferred autorun re-run — we'd then wipe the new login
- * along with the dead logout.
- */
-Accounts.onLogout(() => {
-	conn._outstandingMethodBlocks = [];
-	conn._methodInvokers = Object.create(null);
-	// Also wipe _methodsBlockingQuiescence: the logout method's wait-flag
-	// is still here because its server response never landed (DDPSDK was
-	// torn down by makeClientLoggedOut). With it left in place,
-	// _waitingForQuiescence() stays true and _livedata_data buffers every
-	// subsequent frame — including the synthetic `updated` we inject via
-	// processResult to trigger dataVisible on the next method invoker. The
-	// invoker would then sit with _methodResult set, _dataVisible false,
-	// and the login callback never fires.
+	conn._subsBeingRevived = Object.create(null);
 	conn._methodsBlockingQuiescence = Object.create(null);
 	conn._messagesBufferedUntilQuiescence = [];
-	conn._subsBeingRevived = Object.create(null);
-});
+
+	let saw: string | undefined = userIdStore.getState();
+	userIdStore.subscribe((next) => {
+		if (next === saw) return;
+		saw = next;
+		if (next) {
+			(Accounts as unknown as { _setLoggingIn?: (v: boolean) => void })._setLoggingIn?.(false);
+		}
+	});
+
+	Accounts.onLogout(() => {
+		conn._outstandingMethodBlocks = [];
+		conn._methodInvokers = Object.create(null);
+		conn._methodsBlockingQuiescence = Object.create(null);
+		conn._messagesBufferedUntilQuiescence = [];
+		conn._subsBeingRevived = Object.create(null);
+	});
+}