Skip to content

Conversation

@ellisonbg
Copy link
Collaborator

This add a new YMessageType.YDOC_VERSION field and wires up YRoom to send that to every new client connection. Each YRoom has a new _ydoc_version that is a UUID that is recreated anytime the ydoc in created. From the docstring:

If the client has a different ydoc version, it should delete its ydoc, create a new one, and save the new ydoc version. The server must send the ydoc version to new clients before the sync1/sync2 handshake, but can also send it at any time. Clients must initiate sync1/sync2 anytime they receive a ydoc version message.

Copy link
Collaborator

@dlqqq dlqqq left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@ellisonbg Thanks for opening this! Left some minor comments below.

High-level question: Do we have any immediate plans for implementing features that mutate the YDoc's history? There are still some notable issues with the current backend, so it may make more sense to iron those out first, before adding new features.

"""Subscription to awareness changes."""
_ydoc_subscription: pycrdt.Subscription
"""Subscription to YDoc changes."""
_ydoc_version: str
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should be of type bytes, right?

"""Define a new YMessageType enum that include a YDOC_VERSION."""
SYNC = 0
AWARENESS = 1
YDOC_VERSION: 2
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
YDOC_VERSION: 2
YDOC_VERSION = 2

can also send it at any time. Clients must initiate sync1/sync2 anytime
they receive a ydoc version message.
"""
new_client = self.clients.get(client_id)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should there be special handling if the client_id is not mapped?

@dlqqq
Copy link
Collaborator

dlqqq commented May 16, 2025

As discussed at standup yesterday, we may explore other ways of informing clients to re-sync. One way is to use special 4xxx Websocket close codes instead; this has the benefit of keeping our Yjs protocol implementation simple & aligned with other Yjs applications.

This work is being tracked in #45.

@ellisonbg
Copy link
Collaborator Author

Closing as we are taking a different direction

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants