fix(repeater): stop reconnecting after the socket is torn down

[aborovsky]

relates-to: #675

[aborovsky]

Summary

Fixes the fatal Sentry issue Error: Please make sure that repeater established a connection with host. (~76K events), which is thrown from get socket inside Timeout._onTimeout.

DefaultRepeaterServer has exactly one timer that dereferences the socket — the reconnection timer in scheduleReconnection:

this.connectionTimer = setTimeout(() => this.socket.connect(), delay);

this.socket throws whenever _socket is undefined, and _socket is only cleared by disconnect(). So the error means a reconnection timer fired after teardown. A throw inside a timer callback has no frame to catch it, hence Fatal / Unhandled.

How it happens

handleConnectionError emitted ERROR and then scheduled a reconnection unconditionally:

if (data && this.suppressConnectionError(data)) {
  this.events.emit(RepeaterServerEvents.ERROR, { ...data, message: err.message });
}

// Try reconnect in any case.
this.scheduleReconnection();

events.emit is synchronous and so is the whole downstream chain:

emit(ERROR) → wrapEventListener → ServerRepeaterLauncher.handleError → isCriticalError → handleCriticalError → close() → disconnect() → _socket = undefined

Control then returns to scheduleReconnection(), which installs a fresh timer on an already-disposed socket. It fires ~1s later and throws.

suppressConnectionError gates on REPEATER_UNAUTHORIZED / REPEATER_NOT_PERMITTED, and both are in the launcher's critical list — so every repeater started with a revoked token or without permission crashed this way, deterministically.

This was a regression from #675, which removed the return that used to end that branch.

Why the volume is so high

Two amplifiers, both from #675:

1. scheduleReconnection overwrote connectionTimer without clearing the previous handle. Every failed attempt during an outage leaked another timer, and disconnect() could only cancel the last one — so all the leaked ones fired and threw.
2. The delay bounds were inverted: MIN_RECONNECTION_DELAY = 5_000 vs MAX_RECONNECTION_DELAY = 1_000. Since the last step is Math.min(delay, MAX), the exponential backoff above it was dead code and every retry landed at 1s. socket.io also got reconnectionDelay: 5000 with reconnectionDelayMax: 1000.

Changes

• Don't reconnect on terminal errors. Restore the early return for REPEATER_UNAUTHORIZED / REPEATER_NOT_PERMITTED; retrying an authorization rejection can't succeed. Renamed suppressConnectionError → isTerminalConnectionError, which is what it actually tests.
• Make teardown authoritative. New disposed flag, set first in disconnect() and cleared in connect(). scheduleReconnection bails when set, as does the manual reconnect on io server disconnect.
• Never dereference the socket through the throwing getter in deferred callbacks. The reconnection timer and deploy's process.nextTick now use this._socket?.…, so a late callback is a no-op instead of a fatal throw. deploy falls through to its existing No response. timeout, which callers already handle.
• Fix the timer leak. clearConnectionTimer() at the top of scheduleReconnection keeps a single pending attempt; clearConnectionTimer now also resets the handle to undefined.
• Fix the delay bounds so MIN (1s) < MAX (5s), which revives the backoff and makes the socket.io options coherent. The timer is deliberately left referenced so a pending attempt keeps a long-running Repeater alive during an outage.
• Drop manager listeners on teardown. io() caches managers per URI, so without this a subsequent connect() would double-register the reserved-event handlers. Safe at that point: socket.disconnect() has already destroyed the socket and closed the manager.

Tests

New src/Repeater/DefaultRepeaterServer.spec.ts (9 cases), with socket.io-client mocked and fake timers.

On next without the source change, 6 of them fail — including two that fail with the exact Sentry message:

✕ should keep a single pending reconnection while attempts keep failing
✕ should not reconnect after a terminal repeater_unauthorized connection error
✕ should not reconnect after a terminal repeater_not_permitted connection error
✕ should not touch the socket when a pending reconnection fires after teardown
✕ should not schedule a reconnection when a connection error arrives during teardown
✕ should time out rather than throw when the socket is torn down before the deploy is flushed

Verification

• npm run test:unit — 270 passed, 25 suites
• npm run lint — clean
• npm run format — clean
• npm run build — webpack compiled successfully
• npx tsc --noEmit — one pre-existing error in src/RequestExecutor/HttpRequestExecutor.spec.ts:158, present on next and unrelated to this change

Note, not addressed here

RepeaterServerEvents.ERROR is the string 'error' on a plain EventEmitter, so emitting it with no listener registered throws ERR_UNHANDLED_ERROR. Production is covered because ServerRepeaterLauncher.subscribeToEvents always registers one, but it's a sharp edge worth a separate look.

[aborovsky]

• Don't merge before testing locally
• Ensure E2E tests passed for feature branch