You want to:

• report a bug
• request a feature

Current behaviour

• socket.io instantiates an adapter, but does not wait for a callback that it is ready. This works fine for many scenarios, but not one where the adapter needs to spool up long-running processes where the adapter is not ready to do work until they are completed. Connections from clients are handled immediately, and if you use a simple pattern of emit-on-connect from client, an early client can easily connect prior to adapter readiness.
• socket.io calls functions on the adapter, and then immediately invokes its own internal callback function with an argument of null.
• socket.io does not notify its adapter that it is shutting down (closing). As a result, there is no opportunity to stop long-running processes within the socket or disconnect from whatever scale-out solution is being used.

Expected behaviour

• socket.io should pass a callback to the adapter constructor and wait for it to be called prior to continuing to stand up.
• socket.io should pass a callback function to adapter functions and then use that to trigger callback to the rest of the socket.io stack.
• socket.io should call a method on the adapter to indicate shutdown. It need not wait for a callback, because if shutdown fails, what are you going to do -- not shut down? The in-memory adapter can simply make this function a no-op. While I haven't reviewed the Redis adapter in enough depth to see if there is utility to this function in that adapter, I would imagine that it would be good to detach from Redis to return system resources.

Other information (e.g. stacktraces, related issues, suggestions how to fix)

This is particularly critical for the adapter that I have built that works with AWS SQS/SNS:
https://github.com/thinkalpha/socket.io-sqs (socket.io-sqs on npm)

For example, actions like addAll can't be properly handled in time; e.g. if you addAll a socket to room xxx and then immediately .to(xxx).emit(...), your message doesn't necessarily end up back at that socket.