What happened?
Environment: superdoc 2.6.0, v2 collaboration with the y-websocket provider against a self-hosted server (a Cloudflare Durable Object speaking the standard y-websocket protocol). Two browsers in the same room - text, cursors and tracked changes all sync fine in both directions.
While testing comments in collab I hit two related problems, and after digging through the dist bundle I think they share a single root cause.
What I found in the bundle
Comment sync between clients works by writing mutations into the shared Yjs array (ydoc.getArray('comments')) via syncCommentsToClients() - every client observes that array and reloads its comment store when it changes remotely.
In the v2 editor path though, addCommentInternal branches into the v2 comments adapter (v2Adapter.reply / commitPendingComment). That branch reconciles the local store and emits the local comments-update event, but never calls syncCommentsToClients - while the legacy branch right below it does call it. So in v2 mode nothing ever writes the shared comments array, and the observer refresh path is left with nothing to react to.
I also looked at 1.46.1 for comparison: addComment there has no adapter branch and always calls syncCommentsToClients, so replies used to sync - this looks like a v2 regression rather than intended behavior.
Symptom 1: replies never reach the other client
Top-level comments still cross because they anchor a mark inside the document, which travels with the document updates. Replies have no anchor, so with the shared-array write missing they only exist in the authoring client's store.
One detail that convinced me this is not a rendering stall: when A later writes its own reply, the reconcile surfaces only A's local state - B's reply genuinely never arrived in A's engine.
Replies don't survive a close/reopen either: after reopening the document they are gone for everyone, including the client that wrote them. Which fits the root cause - they only ever existed in that client's in-memory store, never in the document or the shared array.
Symptom 2: remote top-level comments don't show up until the store is poked
When A adds a top-level comment, B's document shows the highlight, but B's sidebar stays empty until something forces a store re-read - switching document mode away and back, or any local comment interaction. The data is there (the mark is in B's document); the sidebar just never refreshes from collaboration, because its refresh trigger is the shared array that v2 never writes.
Probably the same path: a client joining an existing room can miss the initial sidebar mount entirely until the same mode round-trip re-mounts it.
Why I don't think it's the transport
The server just relays opaque yjs update frames and has no comment-aware code - text, cursors, tracked changes and top-level comment anchors all cross the same pipe in the same session. And symptom 1 shows up at the logic level in the bundle anyway: the v2 reply path has no call that would put the reply on the wire.
Expected
v2 comment mutations (comments and replies) take part in collaboration sync like the v1 path did: broadcast to the other clients, and remote sidebars refresh without needing local interaction.
Might be adjacent to #3603 but it looks distinct - that one is about rendering tracked-change cards from a loaded Y.Doc; this is live comment mutations never reaching the shared array.
Happy to provide more details or test a fix.
Steps to reproduce
Symptom 1:
- Two clients, A and B, in the same room.
- A adds a comment - B sees it.
- B replies to that comment.
- A never sees the reply: not live, not after switching document modes, not even after closing and reopening the document.
- After a close/reopen the reply is gone for everyone - including B, who wrote it.
Symptom 2:
- Same two clients.
- A adds a top-level comment.
- B's document shows the highlight, but B's sidebar doesn't show the comment until a document-mode round-trip or any local comment interaction.
SuperDoc version
2.6.0
Browser
Chrome
Additional context
No response
What happened?
Environment: superdoc 2.6.0, v2 collaboration with the y-websocket provider against a self-hosted server (a Cloudflare Durable Object speaking the standard y-websocket protocol). Two browsers in the same room - text, cursors and tracked changes all sync fine in both directions.
While testing comments in collab I hit two related problems, and after digging through the dist bundle I think they share a single root cause.
What I found in the bundle
Comment sync between clients works by writing mutations into the shared Yjs array (
ydoc.getArray('comments')) viasyncCommentsToClients()- every client observes that array and reloads its comment store when it changes remotely.In the v2 editor path though,
addCommentInternalbranches into the v2 comments adapter (v2Adapter.reply/commitPendingComment). That branch reconciles the local store and emits the localcomments-updateevent, but never callssyncCommentsToClients- while the legacy branch right below it does call it. So in v2 mode nothing ever writes the shared comments array, and the observer refresh path is left with nothing to react to.I also looked at 1.46.1 for comparison:
addCommentthere has no adapter branch and always callssyncCommentsToClients, so replies used to sync - this looks like a v2 regression rather than intended behavior.Symptom 1: replies never reach the other client
Top-level comments still cross because they anchor a mark inside the document, which travels with the document updates. Replies have no anchor, so with the shared-array write missing they only exist in the authoring client's store.
One detail that convinced me this is not a rendering stall: when A later writes its own reply, the reconcile surfaces only A's local state - B's reply genuinely never arrived in A's engine.
Replies don't survive a close/reopen either: after reopening the document they are gone for everyone, including the client that wrote them. Which fits the root cause - they only ever existed in that client's in-memory store, never in the document or the shared array.
Symptom 2: remote top-level comments don't show up until the store is poked
When A adds a top-level comment, B's document shows the highlight, but B's sidebar stays empty until something forces a store re-read - switching document mode away and back, or any local comment interaction. The data is there (the mark is in B's document); the sidebar just never refreshes from collaboration, because its refresh trigger is the shared array that v2 never writes.
Probably the same path: a client joining an existing room can miss the initial sidebar mount entirely until the same mode round-trip re-mounts it.
Why I don't think it's the transport
The server just relays opaque yjs update frames and has no comment-aware code - text, cursors, tracked changes and top-level comment anchors all cross the same pipe in the same session. And symptom 1 shows up at the logic level in the bundle anyway: the v2 reply path has no call that would put the reply on the wire.
Expected
v2 comment mutations (comments and replies) take part in collaboration sync like the v1 path did: broadcast to the other clients, and remote sidebars refresh without needing local interaction.
Might be adjacent to #3603 but it looks distinct - that one is about rendering tracked-change cards from a loaded Y.Doc; this is live comment mutations never reaching the shared array.
Happy to provide more details or test a fix.
Steps to reproduce
Symptom 1:
Symptom 2:
SuperDoc version
2.6.0
Browser
Chrome
Additional context
No response