Possible data loss after Document Server connection failure #381

Activity

1. apfelpfluecker

   added

   bugSomething isn't workingSomething isn't working

   on Jun 25, 2026
2. chadek commented on Sep 15, 2026

   

   chadek

   on Sep 15, 2026

   Collaborator

   More actions

   Fixed for v0.4.0, by #396 — the cause, not the data, which I am afraid is gone: nothing survives of a document whose server-side change list was discarded, and there is no cache or temporary file to recover it from beyond what occ documentserver:flush could still write if that instance's documents are somehow still open.

   What you describe — weeks of editing, regular closing and reopening, and a file in Nextcloud stuck at an old version with no version history in between — is the ordinary behaviour of this app before v0.4.0 rather than a consequence of the document server becoming unavailable. It is the same root cause as #100.

   What was wrong. The editor's "all changes are saved" meant the changes had reached this server's database, not that they had reached the file. Nothing wrote the file until the last participant had left and the Cleanup background job had run. On an instance whose cron is slow, misconfigured, or set to AJAX, a document could be edited all day with nothing on disk — and a browser closed at the wrong moment lost the lot. Worse, the server never noticed an editor leaving at all: a document server that holds a WebSocket learns of it from the socket closing, but this one is polled over HTTP, so the pending poll was simply dropped and nothing ran to notice.

   What changed (#396, and #387 for the session accounting):

   • While you are editing. A save writes the document out if it has been longer than autosave_interval (60 s by default, 0 turns it off) since the last write — from the editing path itself, not from the background job. It costs one document assembly per interval per document being edited, however much is typed in between, and none at all while nobody is typing.
   • When the last editor leaves. The editor says goodbye on its way out and the server acts on it: the session ends, the people still in the document are told, and if that was the last participant the document is written and disposed of immediately. Two paths, because sdkjs only covers one: its own close command, and a beacon sent by the page hosting the editor frame (it has to be the host page — a request started by a frame that is being detached is cancelled with it).
   • Expired sessions no longer count as participants. Rows were only deleted by the background job, so between two runs the table held every session that had ever stopped polling. Counting those meant a document was never seen to be empty, and the write fell back to whenever the job next ran — which is the wait this issue is about.
   • The background job still runs, and now writes documents that are being edited instead of skipping them, so it still catches a browser that crashed or a server restarted mid-edit. It is no longer what saving depends on.

   To change the interval:

   occ config:app:set documentserver_community autosave_interval --value=120
   

   Proof. Two regression tests, driving real editors in headless chromium and reading the file on disk after each step — no cron, no occ documentserver:flush anywhere in the run. Against master just now, Nextcloud 34, ONLYOFFICE connector 10.1, bundled Euro-Office 9.3.4:

   tests/rig/autosave_test.py — the file is written while the document is open:

   ==> [1] type AUTO485531, nothing else
      file: {'AUTO485531': True} | doc folders: 1 | changes: 71
   
   ==> [2] type AUTO485532 straight away, inside the 45s interval
      file: {'AUTO485531': True, 'AUTO485532': False}
   
   ==> [3] wait out the interval, then type AUTO485533
      file: {'AUTO485531': True, 'AUTO485532': True, 'AUTO485533': True}
   
   ==> [4] type AUTO485534 and close the editor
      closing: destroyEditor()
      file: {'AUTO485531': True, 'AUTO485532': True, 'AUTO485533': True, 'AUTO485534': True}
      doc folders: 0 | changes: 0 | sessions: 0
   
      VERDICT: saving during editing works
   -- autosave: PASS in 183s
   

   Step 1 is the whole issue: the text is in the Nextcloud file seconds after being typed, with the document still open. Step 2 is the cost control — a save inside the interval must not re-assemble the document. Step 4 is closing the editor: everything is in the file and the document is disposed of on the spot.

   tests/rig/leave_test.py — two participants, and nobody runs anything:

   ==> [1] both type
      sessions: 2
   
   ==> [2] A closes the editor while B is still in the document
      A closing: destroyEditor()
      sessions: 1 | doc folders: 1 | changes: 158
   
   ==> [3] B keeps typing, and it still reaches the file
      file: {'LEAVE49059-A1': True, 'LEAVE49059-B1': True, 'LEAVE49059-B2': True}
   
   ==> [4] B types once more and closes the tab
      file: {'LEAVE49059-A1': True, 'LEAVE49059-B1': True, 'LEAVE49059-B2': True, 'LEAVE49059-B3': True}
      doc folders: 0 | changes: 0 | sessions: 0
   
   ==> [5] reopen the document: the editor must show what was typed
      markers missing from the reopened document: none
   
      VERDICT: leaving a document saves it
   -- leave: PASS in 284s
   

   Step 2 is the other half of it — one person leaving must not end the document for everybody else — and step 5 reopens the file and asks the editor's own document model what it displays, rather than trusting the write.

   The whole suite is green on master as of this comment: formats, smoke (every format opens, edits and reaches the file), flush-live, autosave, leave, twotab, coedit, coedit-xlsx, forcesave, chat. It runs in CI on pull requests and weekly, so this does not quietly regress again.

   If the instance still exists and any of those documents are somehow still open on it, occ documentserver:flush on 0.4.0 would write them out — but after a "document server is not available" notification that is unlikely.

   ❤️React with ❤️1Reacted by Jakob Krueger
3. chadek

   closed this as completedin #400on Sep 16, 2026