-
Notifications
You must be signed in to change notification settings - Fork 4.7k
Real-time collaboration: Persist CRDT documents on autosave #75105
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
base: trunk
Are you sure you want to change the base?
Real-time collaboration: Persist CRDT documents on autosave #75105
Conversation
|
Size Change: +23 B (0%) Total Size: 3 MB
ℹ️ View Unchanged
|
|
Flaky tests detected in c63d85e. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/21531356336
|
|
The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message. To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook. |
alecgeatches
left a comment
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.
Tested according to your instructions and was able to reproduce on trunk but not in this branch. 👍
What?
Persist CRDT documents on autosaves (in addition to manual saves).
Why?
We persist CRDT documents in order to solve the "initialization" problem and avoid duplicate updates. When saving a post, we also save a persisted CRDT document alongside it (in post meta) that represents its current state. This document is used as a "shared starting point" for all users in the session.
If the post is updated "out-of-band" (e.g., by a WP-CLI command), then we can compare the post against the persisted CRDT document, compute the necessary updates, and apply them to the CRDT document.
We recently discovered that autosaves are sometimes applied to the post itself instead of a revision:
https://github.com/WordPress/wordpress-develop/blob/dc62ecbc345ca1b8d1801eca794d71755b7568f1/src/wp-includes/rest-api/endpoints/class-wp-rest-autosaves-controller.php#L235-L244
In those situations, the post data becomes out of sync with the persisted CRDT document. If a editor in a collaboration session refreshes the browser, or a new editor joins, they will perceive the autosave as an "out-of-band" update, compute the necessary updates, and apply them to the CRDT document—which will then be synced to peers.
Therefore, whatever updates were captured by the autosave will effectively be duplicated on every page load, for the lifetime of that collaboration session.
To avoid this, we need to persist CRDT documents with autosaves as well. This does result in nominally increased bandwidth and storage, but should not be significant.
How?
Unfortunately, simply adding the persisted CRDT document to the payload of the autosave is not sufficient. In the problematic code path, the backend calls
wp_update_post(withoutmeta_input) and does not call the special post meta handling increate_post_autosave.To navigate this, we filter
rest_prepare_autosaveand update the post meta manually.Testing Instructions
Screenshots or screencast
Before
before.mov
After
after.mov