Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Websocket closes on tab minify/switch after +/- 30s. How to handle? #160

Open
nvanhoeck-dpgmedia opened this issue Oct 30, 2023 · 0 comments
Labels
wontfix This will not be worked on

Comments

@nvanhoeck-dpgmedia
Copy link

nvanhoeck-dpgmedia commented Oct 30, 2023

Hi there!

My team at DPG-Media have a question about the way we need to deal with something we encountered implementing the YJS-websocket-provider in our codebase. We have a frontend setup which uses SyncedStore and the yjs Websocket-provider to setup a communication between clients and a websocket-server. The communication goes pretty well, aside from some quirks.

One of these quirks, we discovered when debugging, is that minifying the tab or leaving the tab will cause the websocket connection to send a on 'close' message to this server after a certain amount of seconds.

The way we implemented this now is with the idea that a on 'close' really means no connection at all, thus the tab closed, the application stopped or the internet connection is lost. This led us to some issues, since a close was believed that nobody was actually having a browser open anymore. There has been logic build upon this assumption, that executes a cleanup functionality when not a single websocket is connected anymore, removing and destroying the YDoc to which all these clients have been connected to.

We are now looking for a solution to prevent this cleanup from happening and find a better way to handle and interpret the closing of a websocket message. The reason is because we have found a bug where there are 2 users working on a document, both minifies their tabs, and both send a on 'close' message to the websocket server. This cleans up the document. Then client A opens the tab again and is able to continue to work on a new instance of this document. Client A then closes the browser. Client B now opens its browser, but is not able to get its changes from the Client A and can start working on the document with the changes from Client A being dismissed.

We hope for guidance in this setup, since we lack the true knowledge of how the YJS websocket-provider works under the hood. This lead to some questions we don't know how to answer without assistance:

  1. How do we have to interpret a on 'close' message send by the Websocket. Do we have to assume a close isn't actually a close, but a temporary leave and should be in sync again the moment the tab gets opened again?
  2. What is the best practice on cleaning up an Ydoc shared between multiple clients? We don't want Ydocs hanging in memory when there is nobody working actively on these documents.
  3. Is it normal that when you have your tab minified and changes are send to the server and clients, when you open your tab again, you don't get these updates on the client-side? Do we have to built-in some mechanism to deal with new changes when opening the tab again? Or is something wrong with the sync1Step and sync2Step? We would expect that reconnecting to the websocket server would load these new updates into the front-end, but that doesn't seem to happen. It might be a bad implementation on our side as well.

If more info is required, please let us know.

Thanks in advance!

Huly®: YJS-553

@nvanhoeck-dpgmedia nvanhoeck-dpgmedia added the wontfix This will not be worked on label Oct 30, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
wontfix This will not be worked on
Projects
None yet
Development

No branches or pull requests

1 participant