-
Notifications
You must be signed in to change notification settings - Fork 94
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
Always initialize with the same yjs document if no state is present #5589
Conversation
b23accd
to
5503673
Compare
Signed-off-by: Julius Härtl <jus@bitgrid.net>
Signed-off-by: Julius Härtl <jus@bitgrid.net>
Signed-off-by: Julius Härtl <jus@bitgrid.net>
Signed-off-by: Julius Härtl <jus@bitgrid.net>
434c3d0
to
9a52473
Compare
/backport to stable29 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks a lot for diving into this. The explanations seem reasonable to me and sound like a good approach to address the underlying problem.
For now I only have minor comments.
// to still push a state | ||
ydoc.clientID = 0 | ||
const type = /** @type {XmlFragment} */ (ydoc.get('default', XmlFragment)) | ||
if (!type.doc) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't understand this part.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Clarified also with a comment in the code
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the code walkthrough in the call.
Signed-off-by: Julius Härtl <jus@bitgrid.net>
Signed-off-by: Julius Härtl <jus@bitgrid.net>
9a52473
to
ee94449
Compare
Fix #5574
Fix #4881
When restructuring the y.js state handling we changed the behaviour to only apply the initial content for the first session. Since we no longer cleanup the document state we introduced an issue where a second read only document would no longer show content as the steps the first session tried to push to set the content never appeared (as the read only session cannot push any steps). Apart from this there might still be possible breakage of documents if pushing the steps fails or is not happening for some reason.
I tried to summarize the problems of the current approach in a small diagram:
This is a new approach that fixes the above issue and also cleans up the way we generally initialize the y.js document (which as a side effect also fixes #4881). While this is not the ideal approach from reading up on y.js handling the initial document state, this seems the most reasonable given the technical limitation we have on the backend where we cannot build a y.js document based on the markdown content right now.
With this change we now always initialize a idempotent y.js document state if there is no state file present. This allows us to have the same state accross sessions, which can then pick up syncing their edits immediately and no longer require a step to be pushed and synced from the first to other sessions to have the initial content. On the first save the y.js state is persisted on the server and will be used for any further sessions.
Tests
Some additional cypress tests cover the different scenarios to pick up a document that either starts from the client created initial state or from the server stored one.
Testing concurrent sessions is not that straight forward with cypress, but we could think about recording some edits and replying the API requests while having one tab open showing the changes and asserting the document. However this is left for another time for now.
Additional jest test I used for exploring options, not entirely sure if that is actually useful yet to have in our codebase
Further references