search

ueberdosis / hocuspocus

The CRDT Yjs WebSocket backend for conflict-free real-time collaboration in your app.
https://tiptap.dev/docs/hocuspocus/introduction
MIT License
1.34k stars 128 forks source link

Provider.disconnect prevents subsequent provider.connect from working #782

Closed jamesopti closed 9 months ago

jamesopti commented 10 months ago

Description To manually want to close the websocket provider connection to Hocuspocus, you can call provider.disconnect

However, subsequently calling provider.connect does not properly reconnect the provider instance to the websocket instance and send the edits over the wire.

This appears to have been introduced in #727

Context/Questions

We've long used provider.disconnect() when a TipTap client backgrounds their browser tab so that our Hocuspocus instance doesn't end up with dozens or more unused websocket connections open for long periods of time. When the tab is foregrounded again, we call provider.connect()

Is there a better way to achieve this behavior?

Steps to reproduce the bug Steps to reproduce the behavior:

  1. Setup a HocuspocusProvider instance
  2. Connect to Hocuspocus Server
  3. Make edits successfully
  4. Invoke providerInstance.disconnect()
  5. Wait a second
  6. Invoke providerInstance.connect()
  7. Make edits to document

Expected behavior The edits are captured by the server

Actual behavior The edits do not get sent

Environment?

Additional context It appears you can workaround this by calling provider.configuration.websocket.attach(provider) instead (which calls provider.connect internally), but its a little yucky:

provider.configuration.websocketProvider.shouldConnect = true
provider.configuration.websocketProvider.attach(provider)

Possibly related to #594

jamesopti commented 10 months ago

I opened #783 to propose a fix for this. I don't LOVE it but I think it works. Open to other ideas