A WebSocket close is not immediate. We should return a Promise, wait for the close event and then resolve. However, the main problem is that we allow to .connect immediately after a .disconnect which results in racy behaviour as both WebSocket connections are bound to the same event handlers.
This would be a major change and requires significant refactoring. For now, applications should always either:
Wait for the connection-closed event, or
Unbind all events after a .disconnect, throw the SaltyRTC instance away and create a new one. Even if you do this, be prepared to see log messages from previous connections (I'm working on removing this).
A WebSocket close is not immediate. We should return a
Promise, wait for thecloseevent and then resolve. However, the main problem is that we allow to.connectimmediately after a.disconnectwhich results in racy behaviour as both WebSocket connections are bound to the same event handlers.This would be a major change and requires significant refactoring. For now, applications should always either:
connection-closedevent, or.disconnect, throw theSaltyRTCinstance away and create a new one. Even if you do this, be prepared to see log messages from previous connections (I'm working on removing this).