Fix how remote ops are applied during open phase #46
Conversation
This file contains 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
It no longer applies ops while the @State is "opening", instead any remote ops received get put into a queue which gets replayed once we get the open success message back from the server.
Essentially a regression test to make sure we don't break the fix for how remote ops should be applied after reopening a document with pending ops that haven't been acknowledged by the server yet.
tomharrold
approved these changes
Mar 27, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
This fixes a rare but very annoying bug where you have 2 clients actively connected to the same document, one disconnects, but continues to make changes (creating a pending op), and the other continues to make changes, when the disconnected client reconnects, it can in rare circumstances receive the remote op message(s) originating from the other client before the reconnecting client receives the document open confirmation.
It results in the document version going out of sync in the reconnecting client and general odd behaviour from then on.
Inserts will mostly continue working as normal, delete will not work, some ops will be outright rejected depending on which part of a text subdocument they are trying to edit and whether or not it conflicts with the remote ops that were applied during the open phase. While the server document remains in "good condition" after this happens, the client document will corrupt itself more and more until the user realises something is wrong and reloads the page. Not ideal.
Thankfully I was able to write a test that does verify that the fix works, so with the fix the tests should pass, if you
git revert 64803f0and run the tests again, they should fail.If you want to verify the fix within the application it's quite involved so let me know and I can give a demo.