test(client): fix three flaky tests around socket/connect lifecycle

[nkaradzhov]

Summary

Three flaky tests in packages/client consolidated into one branch, one commit each:

• Socket > socketTimeout > should timeout with positive socketTimeout values — listener attachment race let the socket-timeout error surface as uncaught on slow CI.
• Client > ConnectionTimeoutError — connectTimeout: 1 raced a 1ms event-loop block; on fast hardware the connect event landed before the timeout callback and the connection succeeded.
• Client > PubSub > should resubscribe — once(subscriber, 'error') removed itself after the first emit, leaving the second (transient) error during the forced reconnect uncaught.

All three are wired up via the same root-cause shape: relying on a one-shot once listener for an event source that can fire more than once. The fix in each case is a permanent listener plus a one-shot promise gate to keep the test deterministic.

The ConnectionTimeoutError case is purely a timing margin bump.

Test plan

• should timeout with positive socketTimeout values × 10 runs locally — all pass
• ConnectionTimeoutError × 5 runs locally — all pass
• should resubscribe × 10 runs locally — all pass
• Full Socket spec — 11/11 pass
• Full PubSub spec — 5/5 pass
• CI on Node 18, 20, 22, 24

🤖 Generated with Claude Code

---

Note

Low Risk
Only test harness changes in spec files; no production client or socket behavior is modified.

Overview
Stabilizes three flaky client integration tests that were racing socket/connect lifecycle timing and mishandling multiple error emissions.

For Pub/Sub resubscribe and socketTimeout, tests no longer rely on once(..., 'error') alone: they add a permanent error listener plus a one-shot promise to await the first error while swallowing follow-up errors (e.g. after CLIENT KILL or with reconnectStrategy: false).

The socketTimeout case also connects explicitly (disableClientSetup), bumps the timeout to 200ms, sets reconnectStrategy: false, and asserts isOpen synchronously instead of deferring via nextTick.

The ConnectionTimeoutError test blocks the event loop for ~50ms (was ~1ms) so a 1ms connectTimeout reliably fires before a successful connect on fast hosts.

^{Reviewed by Cursor Bugbot for commit e5fdc19. Bugbot is set up for automated code reviews on this repo. Configure here.}

[PavelPashov]

Do we need this array of errors?

[PavelPashov]

This might be a bit simpler

client.on('error', () => {
  // keep a permanent listener for any later error emission
});
const firstError = once(client, 'error') as Promise<[Error]>;
// ...
const [err] = await firstError;

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{Reviewed by Cursor Bugbot for commit e5fdc19. Configure here.}

[cursor]

Unnecessarily complex promise pattern versus simpler once idiom

Low Severity

The should resubscribe test uses a manual resolveFirstError promise-gate pattern (with let resolveFirstError!: () => void and a custom new Promise) while the socketTimeout test in the same PR already demonstrates the simpler and equivalent approach: a permanent no-op on('error') listener paired with once(client, 'error'). The simpler pattern is fewer lines, more idiomatic, captures the actual error object, and maintains consistency across both tests in this PR.

Additional Locations (1)

• packages/client/lib/client/socket.spec.ts#L251-L255

 

^{Reviewed by Cursor Bugbot for commit e5fdc19. Configure here.}