fix(unique-id): do not attempt to append to y-sync plugin transactions #2153
+25
−6
Conversation
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
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
This is because of a bug that we've had for a while, but I was never able to trace down. - We set an initial block id for the initial content (always "initialBlockId" when collaboration is detected) - `y-sync` replaces the document with what it "sees" in the `Y.XmlFragment` we gave it - This causes a transaction to replace the initial content (replacing it with an empty document with a `blockContainer` containing an id of `null`) - The unique id plugin sees this & attempts to correct the missing id, issuing a new transaction - This means there is now a write to the `Y.XmlFragment`\ This write can happen independently to the provider actually synchronizing the content. Meaning, that the `Y.XmlFragment` and `tr.doc` are out of sync when `y-prosemirror` attempts to [restore the selection](https://github.com/yjs/y-prosemirror/blob/ef35266d660c3cd76a491fde243b0c6bee25d585/src/plugins/sync-plugin.js#L634). This is ultimately because `y-prosemirror` is listening to the Y.Doc _after_ it already is accepting the change. Which is totally valid, but ProseMirror doesn't offer a great way to keep these values in-sync. The fix here is to just stop the unique-id extension from attempting to amend any `y-prosemirror` transactions. Ultimately, the remote editor should have already written the correct ID (since to the remote editor, it was the local editor - therefore, the unique-id extension should have run).
nperez0111
force-pushed
the
unique-id-fixes
branch
from
1059b81 to
de1f82a
Compare
@blocknote/ariakit
@blocknote/code-block
@blocknote/core
@blocknote/mantine
@blocknote/react
@blocknote/server-util
@blocknote/shadcn
@blocknote/xl-ai
@blocknote/xl-docx-exporter
@blocknote/xl-email-exporter
@blocknote/xl-multi-column
@blocknote/xl-odt-exporter
@blocknote/xl-pdf-exporter
commit: |
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.
Summary
This is because of a bug that we've had for a while, but I was never able to trace down.
Rationale
y-syncreplaces the document with what it "sees" in theY.XmlFragmentwe gave itblockContainercontaining an id ofnullwhen usingschema.doc.createAndFill())Y.XmlFragment\This write can happen independently to the provider actually synchronizing the content.
Meaning, that the
Y.XmlFragmentandtr.docare out of sync wheny-prosemirrorattempts to restore the selection.This is ultimately because
y-prosemirroris listening to the Y.Doc after it already is accepting the change. Which is totally valid, but ProseMirror doesn't offer a great way to keep these values in-sync.Changes
The fix here is stop the unique ID appended transaction from even having to amend the
idbeingnull, but monkey patchingschema.doc.createAndFillto create adocnode which has a validid(set arbitrarily toinitialBlockId).Impact
This reinstates a bug fix that we had prior to the migration of Tiptap V3, in Tiptap V3
isEmptytakes a different code path, so it is not needed for that check any longer. This allows us to have a perfectly valid document when initialized from an emptyY.XmlFragmentimmediately.Testing
I've manually verified that there is no longer a race condition where the selection fails to be restored because the document is smaller than the position it chose to restore to.
Screenshots/Video
Checklist
Additional Notes