Discussion: How to handle transient disconnects?

[dlqqq]

Areas of discussion

Determine what we should do in the UI while the client is disconnected with a non-special close code (e.g. transient disconnects).

• In my opinion, we should totally disable editing while the client is disconnected. When we disconnect, it's not possible to know if the server will still be using the same YDoc when we re-connect.

• For example, a transient network error (somebody pulling the ethernet cable and putting it back) & a server restart (kill -9 <PID> && jupyter lab) are indistinguishable. They will both produce the WS close code 1006. However, we cannot do the SS1 + SS2 handshake without reseting the client's YDoc first when the server restarts.

• Therefore, even if we let disconnected clients continue editing, those edits may be lost on re-connect if the server is using a different history. This is an inconsistent UX: sometimes offline edits can get saved, but other times, they get deleted. It seems safer to assume client edits will be lost, so we should disable edits until we are re-connected.

• Disabling editing doesn't impact local users, since the browser will always be connected to localhost.

[dlqqq]

Related to #9.