[Dev]: Automatic WebSocket reconnections #173
Description
Unmet Need:
Currently, inside the SquireClient, if an error occurs with a websocket, we panic. This is, obviously, not great. Instead, a websocket connection that returns an error or is closed (starts returning None) should be dropped.
Solution:
When we believe a WS connection to be closed, we should drop that WS object. We should then schedule an attempt to re-establish a connection to the server. The re-attempts can be quick at first and then slowly back off over time; however, we should never stop trying to reconnect to the server. The delay between re-attempts can grow to be rather large, though, up to a few minutes.
While we are unable to connect to the server, we should drop any messages that would be otherwise sent.
Challenges/Considerations:
Note that errors caused by deserializing a WS message do not fall into this category of error. We should not drop a WS connection because of that. Failing to deserialize a message should simply result in that message being dropped.
One thing that you must be familiar with is how we work with actors. They are key to this feature.
Definition of Done:
- Panics are removed from the WS message handling
- Schedule a recurring WS request until one is established