"Session ID unknown" (HTTP 400) during rolling deploys: sticky sessions vs Redis adapter for Socket.IO

I'm planning a zero-downtime migration of a small Socket.IO application to a multi-node setup behind a load balancer. During rolling restarts, clients using the default transports can hit the Engine.IO error Session ID unknown (HTTP 400), because the handshake session lives in memory on the node that issued it and a subsequent polling request may land on a different node.

My understanding is that there are two documented mitigations with different trade-offs:

• Enable sticky sessions at the load balancer, optionally combined with transports: ['websocket'] on the client so the connection stays pinned to one node for its lifetime — simple, but it removes the polling fallback for clients behind restrictive proxies.
• Deploy an adapter such as @socket.io/redis-adapter so room membership and broadcasts stay consistent across nodes during the cutover — extra infrastructure, and configuration keys differ between Socket.IO v2 and v3/v4.

The application does use rooms and server-initiated broadcasts, but traffic is low enough that a brief degradation during deploys might be acceptable.

My questions:

1. Is sticky sessions alone sufficient for correctness if broadcasts only need to reach clients on the emitting node during the short deploy window, or does any room usage effectively mandate the Redis adapter?
2. Does forcing WebSocket-only transport meaningfully reduce the risk of Session ID unknown compared with sticky sessions on the default transports?
3. For a small app, is there a documented way to verify cross-node delivery (e.g., emitting from node A to a client on node B) before committing to the adapter?