Tangentially related to #853, when I call disconnect on my web socket, it calls through to engine.stop(). In its completion block, that calls through to self?.forceStop(), which then calls through to the transport's disconnect method, which disconnects everything but doesn't seem to have anything that calls back and tells the socket the disconnect has completed.
I suspect what's happening is that because the delegate for the two streams is set to nil before the streams are closed, all the delegate stuff that would normally get called when the sockets close is not getting called.
Is this considered:
a) expected behavior, and if we manually call disconnect we should just assume it eventually disconnected?
b) a bug, and there should be some kind of indication that the socket disconnected that goes back up through the delegates to the didReceive(event: WebSocketEvent, client: WebSocket) method?
c) Something else I'm not thinking of? 👽
Tangentially related to #853, when I call
disconnecton my web socket, it calls through toengine.stop(). In its completion block, that calls through toself?.forceStop(), which then calls through to the transport's disconnect method, which disconnects everything but doesn't seem to have anything that calls back and tells the socket the disconnect has completed.I suspect what's happening is that because the delegate for the two streams is set to
nilbefore the streams are closed, all the delegate stuff that would normally get called when the sockets close is not getting called.Is this considered:
a) expected behavior, and if we manually call
disconnectwe should just assume it eventually disconnected?b) a bug, and there should be some kind of indication that the socket disconnected that goes back up through the delegates to the
didReceive(event: WebSocketEvent, client: WebSocket)method?c) Something else I'm not thinking of? 👽