Connection health and autoreconnect about matterhorn HOT 8 CLOSED

I see this as being more than a "nice to have". For example, if I'm running a client on my laptop and I shut the lid, then open later it appears that I'm still connected to Mattermost, but in fact the connection is broken.

I think at the very least the connection health component should be part of the minimum client.

from matterhorn.

Yeah, I agree. Tag removed.

from matterhorn.

This feature is halfway there:

• We detect a ping timeout and visually indicate in the top-right corner that the connection is dead
• We sporadically attempt to reconnect, and after reconnecting you'll see new messages as they come in.

Some features which are currently missing:

• We try to reconnect every five seconds, and we probably should have some kind of backoff over time so that we're not perpetually trying to vainly reconnect when we're not connected to the network
• We don't report the health beyond a binary of connected/not connected, and it would be nice to report a good/fair/poor connection quality based on the latency.
• Most importantly, we don't fetch any history on reconnection: you'll see messages from before the drop, and from after, but not from the period you weren't connected.

from matterhorn.

Latest update: we now catch all exceptions in the ping management threads to avoid stderr poisoning when those threads crash. Before, we only caught specific websocket timeout exceptions.

from matterhorn.

Any other thoughts on what we can do before calling this done?

The only thing I can think of is to make the client check for updates when the websocket comes back up (i.e. refresh all state).

from matterhorn.

Yeah, I think refreshing the state is the next obvious thing. After that I think it makes sense to close this issue.

from matterhorn.

As of ead74fb we now refresh messages, but no other state.

from matterhorn.

I'm going to close this one and open another issue for refreshing the rest of the state: "refresh user/channel metadata on reconnect" is significantly different enough from this issue's title of "connection health and autoreconnect" that I think it should be recorded elsewhere.

from matterhorn.