Possible upstream bug: ReferenceError "param is not defined" in AscCommon.sendClientLog causes silent XLSX co-editing save failure (ExitCode 86)

[mosi-kha]

Reporting this as a heads-up / tracking issue — I haven't reproduced it directly on Euro-Office, but it was confirmed upstream in ONLYOFFICE/DocumentServer and Euro-Office is a fork of the same codebase, so it may be present here too.

Upstream reference: ONLYOFFICE/DocumentServer#3711 (confirmed-bug, fixed-release — fix merged upstream, not yet released as of this writing)

Upstream environment:

DocumentServer version: 9.3.1
Deployment: Docker (Kubernetes/Helm)
Integration: Nextcloud + onlyoffice-nextcloud app
File type: XLSX

Reported behavior (upstream):
During collaborative editing of an XLSX file with 6+ simultaneous editors, forced save fails silently. UI shows "All changes saved" but changes are not persisted. converter/out.log shows:

[ERROR] nodeJS - stderr:ReferenceError: param is not defined
at Object.error (:23:318)
at Object.a.AscCommon.qla.a.AscCommon.sendClientLog (:10027:47)
...
DoctRenderer:

[ERROR] nodeJS - ExitCode (code=86;signal=null;error:-86)

The failure is not transient — the same docId fails on all subsequent save retries.

Ask:

Can someone confirm whether this reproduces on the current Euro-Office build (9.3.x)?
If Euro-Office has already pulled the upstream fix for #3711, can that be noted here and this closed as resolved/duplicate?
If not yet pulled, please track/schedule the upstream fix for a future Euro-Office release.

[github-actions]

@moodyjmz @j-base64 Please triage this community-created issue within 48 hours.

[renatoyamane]

Please triage this community-created issue within 48 hours

This triage isn't working 😟

[moodyjmz]

Triaged. This does reproduce here — confirmed by inspection rather than by running it, because the cause turns out to be unconditional. Thanks for the cross-repo heads-up, @mosi-kha; it was the right call to file it.

Root cause

sdkjs/common/Native/native.js — the console shim for the native (DoctRenderer/x2t) JS context:

error: function() { window.native && window.native.ConsoleLog("[error]: " + param); }

error declares no parameter but its body references param, which exists only as a formal parameter of the sibling log/time/timeEnd functions. Every console.error() call in the converter therefore throws ReferenceError: param is not defined.

Your stack trace matches this line byte-exactly. The deployed native.js is 23 lines long, and param sits at column 318 of line 23 — hence <anonymous>:23:318. native.js is the first <file> entry in build/configs/core/DoctRenderer.config, concatenated ahead of sdk-all.js by the converter at runtime (core:DesktopEditor/doctrenderer/editors.cpp:69-75), which is why it lands at the very top of the anonymous source.

Edit — scope of that coordinate. 23:318 is specific to builds produced by the current Closure Compiler toolchain, which is what every release up to and including v9.3.2 used. A pending build-system migration (Euro-Office/sdkjs#65) switches the individually-deployed Native/*.js files to Terser, which lays the minified output out differently. The defect and its source line are unaffected, but anyone matching a future converter trace should re-derive the line/column against their own build rather than reusing 23:318. The stable identifier is the source construct — error in the console shim in common/Native/native.js referencing an undeclared param — not the minified coordinate.

Two commits combined to arm it: the broken body was introduced 2025-11-17, and five weeks later sendClientLog() started routing error-level messages through console.error(). Before that, nothing on the save path ever called it.

Why it causes data loss rather than a bad log line

sendClientLog("error", …) means something else has already gone wrong — in your case the 6+-editor condition, probably related to the ~12 KB JWT you noted. The shim then throws while trying to log it. The throw escapes, DoctRenderer returns <error code="save" />, ExitCode 86, and the original error is destroyed. The client still says "All changes saved".

Being a deterministic code bug and not a race, the same docId fails on every retry — which matches your observation of 954965759 failing at 11:12, 11:32 and 11:34.

Important: fixing this does not fix the underlying co-editing/JWT-size problem that triggers the log call. It converts silent data loss back into a logged error that says what actually went wrong. That underlying issue remains open and separate.

Two corrections to the report

1. There is no upstream fix to pull. ONLYOFFICE/DocumentServer#3711 carries confirmed-bug + fixed-release, but that label reflects internal tracking, not a public commit. No currently-reachable branch of ONLYOFFICE/sdkjs, ONLYOFFICE/core or ONLYOFFICE/server carries a fix, and the newest commit on any live branch of those three is 2026-05-26. The maintainer's estimate is "approximately at the beginning of autumn". So this is not a matter of syncing a submodule — it needed fixing here.

Edit — correcting my own overstatement above. I originally wrote that no public branch of those three repositories had any commit after 2026-05-26. That was too strong, and I should have caught it. ONLYOFFICE/sdkjs commit ca53ff73b1a4 is dated 2026-06-30 and sat on a release/v9.4.1 branch that has since been deleted (the branch now 404s; the commit is still reachable by SHA). My statement was only ever true of currently reachable branches, which is not what I claimed.

It does not change the conclusion: that commit adds an empty ## 9.4.1 changelog heading and contains no code, the branch it lived on is gone, and there is still no public fix available to pull. But the supporting claim was wrong as written, and anyone relying on this comment should have the accurate version.

2. It is not XLSX-specific, or co-editing-specific. XLSX is where it was observed, not what it is about. The shim is format-agnostic and live in every converter operation. Reachable console.error() sites include the Document Builder API (cell/apiBuilder.js, word/apiBuilder.js), macro execution (common/macros.js), and the PDF path. Any converter operation that logs an error can hit this.

Affected versions

v9.3.2 — the current release — is affected. That tag pins the sdkjs submodule at 0d5b3d5d7579, where the defect is present. So are main, master and develop.

Fix

Euro-Office/sdkjs#67 — one word: declare the parameter. Kept deliberately minimal and character-identical to the obvious upstream fix so the eventual ONLYOFFICE sync merges cleanly.

This issue stays open until a DocumentServer image actually ships it. The chain is: sdkjs PR merged → submodule bump in this repo → image build → release. Merging the sdkjs PR changes nothing you can pull, and closing this on that event would misrepresent availability. It will be closed against a released image tag.

Interim mitigation

If you are losing data now and cannot wait for a release, the converter reads this file from disk at runtime, so it can be patched in place:

/var/www/onlyoffice/documentserver/sdkjs/common/Native/native.js

Change error: function() to error: function (param), then delete the V8 code cache or the edit will not take effect:

rm -f /var/www/onlyoffice/documentserver/sdkjs/{word,cell,slide}/sdk-all.cache

Caching is on by default, so this step is not optional. One caveat: check first whether sdkjs/cell/sdk-all.bin exists — if a V8 snapshot is present the converter short-circuits and never reads the JS files, making the edit inert. Euro-Office packaging does not appear to generate one, but verify before relying on this.

This is a stopgap for a data-loss bug, not a supported configuration. It will be overwritten on upgrade, which is fine — the upgrade is the actual fix.

---

@renatoyamane — fair hit on the triage bot. It posts a 48-hour reminder and then has no follow-up, no escalation, and no way to tell whether anyone acted, so the deadline was decorative. Worth fixing separately from this bug.

[renatoyamane]

It posts a 48-hour reminder and then has no follow-up, no escalation, and no way to tell whether anyone acted, so the deadline was decorative. Worth fixing separately from this bug

Hi @moodyjmz, I tried on this way:
Firstly, PR #287 must be done... Then #288, then the PR #289