Summary
With v2 collaboration configured, SuperDoc.save() never resolves: it awaits an immediate-save / immediate-save-finished handshake that structurally cannot occur, because the v2 constructor path never gives the shell document a Y.Doc, and the handshake is gated on doc.ydoc.
Version
superdoc@2.4.0 (registry build; also inspected the published dist in the package).
Analysis (references into the published dist/superdoc.es.js of 2.4.0)
dist/superdoc.es.js:45170-45191 — the save path creates a promise, observes immediate-save-finished, and writes immediate-save only inside if (doc.ydoc). When no shell document has a ydoc, the promise can never resolve.dist/superdoc.es.js:45197-45201 — SuperDoc.save() awaits that promise. dist/superdoc/src/core/SuperDoc.d.ts:739-743 documents the promise as resolving after collaboration writes flush.dist/superdoc.es.js:6072 — the shell document's ydoc is initialized only from params.ydoc.dist/superdoc.es.js:21684-21720 — the v2 constructor path forwards the v2Collaboration config to the internal editor but never assigns the internal editor's Y.Doc back to the shell document.dist/superdoc.es.js:43491-43503 — the external-collaboration path is the only place a Y.Doc is ever assigned to shell documents; the v2 types reject supplying an external Y.Doc/provider pair together with v2 collaboration.- Package-wide search over the non-minified sources finds no other
immediate-save-finished producer. A server-side diagnostic confirmed the persisted v2 root meta map never receives immediate-save.
Expected
await superdoc.save() resolves after collaboration writes flush, as documented in the typings.
Actual
On the v2 collaboration path, await superdoc.save() hangs forever.
Workaround
Constructing SuperDoc in external collaboration mode (external Y.Doc + provider) restores a resolvable save(), since that path assigns the Y.Doc to the shell document.
Suggested fix
Either assign the internal v2 editor's Y.Doc to the shell document so the save handshake can cross the boundary, or document save() as unsupported under v2 collaboration.
Summary
With v2 collaboration configured,
SuperDoc.save()never resolves: it awaits animmediate-save/immediate-save-finishedhandshake that structurally cannot occur, because the v2 constructor path never gives the shell document a Y.Doc, and the handshake is gated ondoc.ydoc.Version
superdoc@2.4.0(registry build; also inspected the published dist in the package).Analysis (references into the published
dist/superdoc.es.jsof 2.4.0)dist/superdoc.es.js:45170-45191— the save path creates a promise, observesimmediate-save-finished, and writesimmediate-saveonly insideif (doc.ydoc). When no shell document has aydoc, the promise can never resolve.dist/superdoc.es.js:45197-45201—SuperDoc.save()awaits that promise.dist/superdoc/src/core/SuperDoc.d.ts:739-743documents the promise as resolving after collaboration writes flush.dist/superdoc.es.js:6072— the shell document'sydocis initialized only fromparams.ydoc.dist/superdoc.es.js:21684-21720— the v2 constructor path forwards thev2Collaborationconfig to the internal editor but never assigns the internal editor's Y.Doc back to the shell document.dist/superdoc.es.js:43491-43503— the external-collaboration path is the only place a Y.Doc is ever assigned to shell documents; the v2 types reject supplying an external Y.Doc/provider pair together with v2 collaboration.immediate-save-finishedproducer. A server-side diagnostic confirmed the persisted v2 rootmetamap never receivesimmediate-save.Expected
await superdoc.save()resolves after collaboration writes flush, as documented in the typings.Actual
On the v2 collaboration path,
await superdoc.save()hangs forever.Workaround
Constructing SuperDoc in external collaboration mode (external Y.Doc + provider) restores a resolvable
save(), since that path assigns the Y.Doc to the shell document.Suggested fix
Either assign the internal v2 editor's Y.Doc to the shell document so the save handshake can cross the boundary, or document
save()as unsupported under v2 collaboration.