RTC: Add "Edit Anyway" mode#77580
Draft
alecgeatches wants to merge 7 commits into
Draft
Conversation
alecgeatches
added
the
[Feature] Real-time Collaboration
|
Warning: Type of PR label mismatch To merge this PR, it requires exactly 1 label indicating the type of PR. Other labels are optional and not being checked here.
Read more about Type labels in Gutenberg. Don't worry if you don't have the required permissions to add labels; the PR reviewer should be able to help with the task. |
github-actions
Bot
added
[Package] Core data
|
Size Change: +2.51 kB (+0.03%) Total Size: 7.77 MB 📦 View Changed
ℹ️ View Unchanged
|
Contributor
Author
|
Update on this PR: I didn't like how 
Note that this is still short of a true merge dialog with diffs, but as mentioned in the PR description this is likely to be a Yjs v14 feature. For now this simplified dialog works, but I want to do some more manual testing and recording of different situations. There are still some failing e2e tests here as well that need looking at. |
Contributor
Author
|
Spent more time today going through different offline scenarios and demoing them for the PR description. For the last scenario "Multiple users with concurrent edits in the same content" I was able to consistently get into a state where one peer had a divergent room: chaos-merge.movAbove, the left user stays online and makes some typo fixes, while offline user 1 adds content and offline user 2 replaces the whole paragraph. The purpose of the video was to show that a complex merge would have a weird result, but what I found was that the second user to re-connect (bottom-right in the video) got stuck in a non-convergent state. "Edit Anyway" mode makes this situation easier to reproduce, but I'm fairly confident this bug is also possible in current RTC by either making changes quickly within one poll cycle or extending poll cycles. Initial analysis suggests it's related to a compaction from the first reconnecting user before the second user reconnects, but I need to spend longer understanding it and make sure it's not caused by this PR. Planning to return here soon to figure that part out. |
Contributor
Author
|
The divergence issue is being addressed in #77980. I plan to move forward with this feature once that PR and also the backport (so the PHP server runs with the fix in |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What?
Currently, RTC requires a fairly consistent connection and will show the "Connection Lost" dialog after a few seconds without a successful sync:
Ideally the sync provider never fails unless a user is offline, but there are bugs that can cause this (#77242, #76968), or the whole backend (like a websocket provider) could go down.
This PR adds an "Edit Anyway" button to the RTC connection error modal. When the sync transport can't recover a connection, users can now choose to keep editing locally instead of being stuck. A small "Offline" status in the header and a snackbar surface the offline state while the user keeps working, and their edits sync back up when the connection returns. Here's what that looks like with a simulated backend error:
edit-anyway-demo.mov
Why?
If we could rely on the disconnection dialog to be triggered only in actual cases of internet problems, then this feature probably wouldn't be needed. However, as mentioned above, there are unknown scenarios and RTC backend issues that can cause the dialog to appear and block a solo user from editing a post. This is frustrating. In many cases the user viewing the disconnection modal is a solo editor anyway.
When the disconnection is transient, due to unrelated errors, or on a solo session, the automatic CRDT merge on reconnect means local editing is usually recoverable. Giving users the explicit choice to continue, with a clear warning about the trade-offs, is a much better experience.
How?
When the user selects "Edit Anyway", the modal flips a new
isEditingWhileDisconnectedflag. The flag is sticky for the session, so subsequent disconnects and reconnects do not re-show the modal, only the disconnected UI.When an offline user makes a save and the server-side CRDT changes, we show a lightweight merge dialog:
Two cases skip the merge pre-check entirely: autosaves while disconnected (they only touch the local
Y.Doc), and the first save of a brand-new post (no server-side CRDT exists yet to compare against).Here's how it works in different scenarios. In all of the examples below, timeouts have been adjusted to show the "Disconnected" dialog faster than normal for testing. The "Offline" toggle simulates a
500from the sync server, which follows the same logic path as a network disconnect or other unexpected sync failure.(S1-1) Solo editor
This is the ideal scenario, when a user clicks "Edit Anyway" and no other user is involved in the post in the meantime. You keep typing into your local
Y.Doc, the header reminds you you're offline, and on save there's no need for a merge because the server-side CRDT doc hasn't changed. When the transport reconnects, the normal sync resumes and the server-side CRDT is updated:solo-editor-1.mov
(S1-2) Solo editor, shaky connection
Very similar to above, a single user uses "Edit Anyway" mode to make changes to a post with an inconsistent connection, intermittently reconnecting to the RTC server. The behavior in this PR only shows the dialog on first disconnection, and subsequent reconnection cycles only show the offline UI and not the dialog again:
solo-editor-2-shaky.mov
(S2) Multiple users, no save
In this scenario a user loses connection to the post, but other users continue to edit the document, and nobody saves. The offline user clicks "Edit Anyway" and continues edits while other users edit the document. When the sync server reconnects, all users converge on the same CRDT doc:
multiple-users-no-save.mov
This generally works if the user has been disconnected for a short time, but incurs greater risk if multiple users made edits to the same content. See S5 below for a more complex merge.
(S3) Multiple users, online save, then offline save
User A disconnects, clicks "Edit Anyway". User B (online) makes changes and saves the document. User A then saves the document in "Edit Anyway" mode. User A will see a lightweight merge dialog "Other changes have been saved to this document while you were disconnected..." about the online save:
multiple-users-online-save-first.mov
Note that when an updated CRDT doc is detected on the server, the user can choose to merge (above) and then save after, or overwrite the server document:
offline-save-overwrite.mov
(S4) Multiple users, offline save, then online save
User A disconnects, clicks "Edit Anyway". User B (online) continues to work in the document. User A (offline) saves, and then user B (online) saves:
offline-then-online-save.mov
This might be counterintuitive, since an offline user sees the overwrite dialog but not an online user. This is a choice, and I'm also open to changing it.
My reasoning is that the merge dialog isn't "you might overwrite someone", but instead "you went offline and edited locally, so your CRDT has diverged from the server's, confirm before overwriting". Online users are actually the source of truth for the live CRDT, and this is about checking with a purposefully divergent offline user. There's no dialog needed for the online user because there's no divergence from their perspective.
(S5) Multiple users with concurrent edits in the same content
This is possible in a regular online session, and is more about how the CRDT handles edits to the same content at the same time. "Edit Anyway"-mode just allows for larger time time gaps and potentially more catastrophic or unexpected merge results. Below, one online user makes changes to content, and ALSO two users who are offline make changes to the same content. When both users reconnect, the CRDT merges in an unpleasant way:
This is the main trade-off of "Edit Anyway". Ideally the warning dialogs should make users aware of this risk, but longer periods of offline activity can lead to wackier merge results. This is essentially unavoidable with an offline mode, except it could be helped with a more in-depth merge dialog (see below).
Future Improvements
Ideally we could update the merge dialog to show fine-grained details about the pending changes, e.g.:
We could show this both on offline reconnect (to the CRDT doc) or during save when changes are already on the server, as we do above. In the ideal case, when a user is the only editor (no concurrent changes), then we wouldn't need to show this dialog at all.
This also helps make merges in the "Publish" state safer, and CRDT merges in other states less likely to cause unexpected conflict. We expect Yjs v14 and the attribute manager (later this year) to make this easier.
Testing Instructions
WIP.
Use of AI Tools
AI assistance: Yes
Tool(s): Claude Code
Used for: The whole process.