In the connect method, if the heartbeat fails for any reason other than a PhoenixException, the PhoenixSocket will stop attempting reconnects, and manually calling connect does nothing. This causes our app to end up in a "broken" state, where the app is disconnected & the user cannot reconnect.
As a consumer of the library, manually calling connect does nothing, since the _ws variable is not reset to null, which means the library simply returns this, but does not reconnect, nor does it throw any kind of exception we could respond to. Furthermore, as the caller, you cannot know that an error has occurred, because nothing is emitted to the errorStream.
In addition, unexpected exceptions are not caught in the _sendHeartbeat and propagated to the consumer (the connect method). Therefore, when something goes wrong in this method, there is no way for the connect method respond appropriately.
This is related to #68. The library should fundamentally ensure that all exceptions are handled. Otherwise, we end up in "Black hole" scenarios, where something goes wrong, but we cannot react to it in any way by attempting a reconnect, resetting the socket entirely, or even just sending the information to an error reporting service like Crashlytics or Sentry so we can evaluate the exception and fix the underlying issue if possible.
In the
connectmethod, if the heartbeat fails for any reason other than aPhoenixException, thePhoenixSocketwill stop attempting reconnects, and manually callingconnectdoes nothing. This causes our app to end up in a "broken" state, where the app is disconnected & the user cannot reconnect.As a consumer of the library, manually calling
connectdoes nothing, since the_wsvariable is not reset tonull, which means the library simply returnsthis, but does not reconnect, nor does it throw any kind of exception we could respond to. Furthermore, as the caller, you cannot know that an error has occurred, because nothing is emitted to theerrorStream.In addition, unexpected exceptions are not caught in the
_sendHeartbeatand propagated to the consumer (theconnectmethod). Therefore, when something goes wrong in this method, there is no way for the connect method respond appropriately.This is related to #68. The library should fundamentally ensure that all exceptions are handled. Otherwise, we end up in "Black hole" scenarios, where something goes wrong, but we cannot react to it in any way by attempting a reconnect, resetting the socket entirely, or even just sending the information to an error reporting service like Crashlytics or Sentry so we can evaluate the exception and fix the underlying issue if possible.
I'll post a PR to address these issues shortly!