replaceFile() seems to silently fail on existing collaborative documents.

[andreHelios]

What happened?

Calling activeEditor.replaceFile(file) on a document that is already open in a collaborative session (liveblocks) completes without any errors, but the editor continues to display the old content. The new imported docx file never replaces the existing document.

The last time this was working from what I can tell was in version: 1.17.0

Steps to reproduce

1. Open an existing collaborative document (we use liveblocks).
2. Wait for the editor and liveblocks to sync.
3. Call superdoc.activeEditor.replaceFile(docxFile) with a valid docx file.
4. The promise resolves, but the document content does not change. The old content remains.

SuperDoc version

1.22.0 and 1.23.0

Browser

Chrome

Additional context

Importing into a brand new document (empty liveblocks room) using replaceFile() works. The issue only seems to occur when importing into a room that already has synced Yjs content.

[linear]

IT-807

[PeterHollens]

Possible root-cause / fix direction after digging into this:

I think the regression window is the parts-sync rewrite in #2325 (v1.18+).

What changed:
In v1.17.0, replaceFile() went through updateYdocDocxData(), which stored the full DOCX in meta.docx (a separate Y.Map) before reinitializing collaboration state. In current code, the collaborative path goes through #insertNewFileData(), which dispatches a ProseMirror tr.replaceWith(...). That then flows through y-prosemirror's PM→Y sync path (updateYFragment()).

My current hypothesis:
updateYFragment() is optimized for diffing incremental edits, but replaceFile() is a wholesale document swap. In a room that already has synced Yjs state, that diff path appears to be the fragile part. My best guess is that the old Y-fragment state and the current PM→Y mapping are no longer a safe basis for a full replacement, so the Y fragment can remain stale even though replaceFile() resolves.

Suggested fix direction:
Before calling #insertNewFileData(), clear the shared Y fragment so the PM→Y sync runs against an empty slate instead of diffing against existing shared content. That matches the fragment-replacement pattern already used in seed-editor-to-ydoc.ts.

Sketch:

const fragment = ydoc.getXmlFragment('supereditor');
if (fragment.length > 0) {
  ydoc.transact(() => {
    fragment.delete(0, fragment.length);
  });
}
this.#insertNewFileData();

Two things worth checking if you take this route:

1. Provider-less Yjs mode: replaceFile() currently only enters the collaborative branch when both ydoc and collaborationProvider exist. Local-only Yjs mode should probably get the same handling.
2. Clear + insert safety: clearing first and then relying on the PM-driven insert means there is a failure window if the insert throws after the clear. I wasn't able to prove a clean atomic version locally because the direct Y→PM path trips collaboration cursor / awareness assumptions in headless tests.

One caveat:
I wasn't able to get a deterministic failing local repro without a real provider-backed setup, so I'd treat the above as a strong hypothesis from tracing the regression path rather than a proven final diagnosis.

[andreHelios]

Thanks for pointing me in the right direction @PeterHollens! I made some updates on my end and it seems to be working now. Much appreciated!