fix(WebSocket): prevent dispatching "open" event if the connection was closed

This change prevents the WebSocket client from dispatching the open event if the connection has been rejected (closed/errored) in the connection event listener.

Note that this keeps the oddity of the client.socket.readtyState being CONNECTING in the connection event listener. This isn't how an actual server connection event behaves, but this is necessary for the interceptor to reject the connection from within before it's ever opened (think of MSW rejecting the WebSocket connection if it's unhandled).

Previous approach

During play testing, I've discovered that client.socket.readyState value was 0 (CONNECTING) in the connection event listener's scope. I believe that's incorrect. The readyState of the intercepted client MUST be 1 (OPEN) in the connection event listener.

The connection event is dispatched when the connection has been successful. In the interceptor's context, any WebSocket connection is considered successful if it has the connection listener.

This is also the behavior when using the actual WebSocket server:

wss.on('connection', (ws) => {
  ws.readyState // 1
})

[!WARNING] If the connection event is dispatched when readyState is OPEN, then MSW cannot reject that connection (onUnhandledRequest). The open even is always emitted, and then the close/error event.

This isn't the right approach. Rejecting a connection is crucial.

The readyState can be CONNECTING in the connection event, that's quite okay.
If you close client.close(), the client must NOT emit the OPEN event on the next frame at all. The closure must take priority (it's already delegated to the next frame). This is easily fixed by checking if (this.readyState !== this.CLOSING) before emitting the open event in the constructor.

mswjs / interceptors

fix(WebSocket): prevent dispatching "open" event if the connection was closed #654

Previous approach

Released: v0.36.3 🎉