V2 can lose a typed suffix during a render failure; save resolves without recovering it

[jfurneaux]

SuperDoc 2.14.0 / @superdoc/react 2.9.0 / @superdoc/sdk 2.11.0. Standalone React page, Hocuspocus collaboration, synthetic Word agreement with a resolved suggestion and a comment. No application autosave runs.

Typing Donor: {{DONOR_NAME}} into an initially focused, editable composition input can leave only Donor: in the shared document. All 22 printable keydown events reach the focused, non-readonly input. After removing CPU throttling and awaiting superdoc.save(), the placeholder remains absent in both other joined browsers.

Reproduction sequence:

1. Seed a fresh V2 Hocuspocus room from a synthetic reviewed DOCX. Append a final paragraph: A later edit requires another review.
2. Join an author, an editor and a viewer in three browser contexts. Await readiness. Save the author once before opening the other contexts; no save runs during typing.
3. Apply Chrome Emulation.setCPUThrottlingRate({ rate: 32 }) to the author context only.
4. Click the rendered final paragraph, press End, verify the composition input is focused, editable and data-v2-ime-host-parked="false", then use Playwright pressSequentially(' Donor: {{DONOR_NAME}}') with its default typing cadence.
5. Check full text in all three browsers. The editing view reports diagnosticCode: PERFORMANCE_ERROR, diagnosticStage: render, then blanks. Both joined browsers contain only the donor prefix.
6. Remove throttling, await the author's superdoc.save(), and inspect both joined browsers again. Save resolves; the placeholder remains absent.

Results: three ordinary controls and three 8x CPU controls preserve all text. Three 32x controls truncate it. Two fresh 32x controls additionally confirm truncation after removing throttling and awaiting save. Input parking by itself is not sufficient: the successful 8x controls also include key events while parked.

Additional fault-injection controls delayed delivery of worker response events while preserving order: at 150 ms, two editing views blank but joined browsers retain full text; at 500 ms, two cases lose the placeholder even after save. These latency controls are separate diagnostics, not required for the CPU reproduction.

Could you investigate the V2 input/commit handling during render failure and advise on a supported fix that retains typed characters? I have the synthetic DOCX, event captures and standalone scripts available.

[jfurneaux]

Attached a portable reproduction with the synthetic DOCX, pinned dependencies and lockfile, standalone server/editor scripts, 24 fresh browser traces, screenshots, event captures and checksums.

superdoc-4007-repro.zip

From the extracted directory, with Node 22.16+:

npm ci
npm run setup
npm run reproduce

I ran all eight cases from this package. Both ordinary controls preserve the full text. Both 150 ms Worker-delay controls blank the author view but preserve shared text. Both 500 ms controls leave the placeholder missing in both joined contexts after SDK save resolves. All 22 printable keydowns reach the focused, non-readonly input.

The CPU-only result is timing dependent: this fresh portable run produced render exceptions but retained the complete text in both joined contexts. The package includes the original CPU-failure event captures and post-save readbacks for comparison. The Worker-delay cases are explicitly labeled fault injection; evidence/VERIFICATION.md records the differences between the original and portable harnesses.

Start with evidence/delay500-0.json and the corresponding joined-editor/viewer traces. Exit code 1 is expected when an assertion reproduces the failure. No application code, customer content or service credentials are included.

ZIP SHA-256: 7b33a96b0b3b962475f16127d2037208475adf4c85617736e1cae5b274e86f2d.

[linear-code]

IT-1609

[jelkes1]

Thanks John. The portable repro is especially helpful.

We’ve pulled this into our investigation and are going to run the package against the current V2 build, with particular attention to the distinction you called out between the view blanking and text failing to reach shared state.

We also have related work around render failures during collaborative editing, so we’ll compare the failure signatures rather than assume they’re the same issue. We will update this thread this week once we’ve run your repro and can say whether it maps to that work or needs a separate fix path.
Cc @caiopizzol @teo-azzollini

[teo-azzollini]

Hi @jfurneaux thank you for flagging this issue as well. I wanted to let you know it has been fixed in pre-release version 2.15.0-next.8. This will also be live in our stable release tomorrow by 12pm PT. Please feel free to give it another test and let us know if you have any questions!