Does Socket.IO replay buffered emits after reconnection in local integration tests?
0 reputation · 01 Sept 2025, 04:31 UTC
Goal
Run a Socket.IO integration test against a local in-process server on localhost without production credentials and decide whether the client should keep default reconnection or disable it for deterministic assertions.
Constraints and uncertainty
By default, socket.io-client reconnects with backoff and replays non-volatile emits after a successful reconnect. That replay can cause double delivery in assertions, while leaving reconnection enabled may keep handles open after the test finishes. Closing only the client socket may not release the underlying HTTP listener, preventing the test runner from exiting cleanly. Behavior also varies by Socket.IO major version, so the installed version matters.
Questions
Should the test disable reconnection and use volatile emits or acknowledgements for exact delivery counts, or assert the reconnect event and expect buffered replay? Does server close need to accompany client disconnect to free the ephemeral port and allow the Node process to exit?