mirror of
https://github.com/d0zingcat/gocryptotrader.git
synced 2026-05-14 15:09:51 +00:00
9854fe1b7c
* Websocket: Prevent panic on Disconnect/Connect Previously we'd set the websocket to disconnected when *either* of the Conn/AuthConn got a disconnect message. This meant that: * The other connection was still functioning * A user would be free to call Connect() * wsReadData() may not have exited Any call to Connect would be acceptable, and we'd probably get a panic from the underlying shared/re-used gorilla websocket: `panic: runtime error: slice bounds out of range [:13501] with capacity 8192` when a new wsReadData goro is started and the old tries to ReadMessage as well, overallocating the buffer. This wouldn't normally occur because trafficMonitor would see traffic (on either connection) and then set the websocket to being connected again. The solution is to treat a Disconnect on either websocket as a call to Shutdown the whole websocket, and then trafficMonitor can reconnect it properly. Unit Testing for this has been difficult. So far I've had to rely on a disruption inside websocket's connectionMonitor itself to reproduce the panic, but from there it's been very consistent. * Websocket: Fix race on DataHandler during shutdown Previously we would encounter situations where shutdown would race and fail TestConnectionMessageErrors, demonstrating that consumers might not be told why their connection is closing. * Do not drain DataHandler on dataMonitor shutdown Consumers should be allowed to process whatever messages were in flight prior to a socket shutdown * Ensure all DataHandler messages are sent to ToRoutine before shutdown This avoids a race where we'd read a message from DataHandler, but then process a shutdown before trying to relay it. The relay is non-blocking anyway, so we can trust that we'd pick up the Shutdown during the next loop. * Send errors to DataHandler before starting a shutdown This just reduces the chance of a race on shutdown processing * Websocket: Log counter of dropped messages