Lost content in collaborative session

[mejo-]

Describe the bug
We have reports of lost content in collaborative editing sessions. The changes by one client are not visible to the other clients.

Current assumption is that the client stops sending its steps after something went wrong.

In one case we got the console log of the faulty client. It contained the following relevant log lines:

[ERROR] text: failed to apply steps due to collission, retrying.
[ERROR] text: Failed to fetch steps due to other reason.
[ERROR] text: Failed to save document.

To Reproduce
No clear reproducer yet.

Server details:

• Nextcloud version: 26.0.2 and 27.0.0 (company instance)

[mejo-]

Description of the situation by @gerbrent the user whose changes didn't propagate:

We were working on a document collaboratively and some text written by one member of the session (me) did not synchronize properly to the document for all other members. The content was there, being added in real time, then all a sudden ALL of the additions added by me - even the previously visible-to-all-members text vanished (me believes he use a shortcut key for formatting, tabs, shift-enter, etc in an unsorted list when it happened).

Text visible/added by me was then copied to an offline doc (backup!) then the browser window was refreshed (i.e. logs might be incomplete).

Then, the previous backed up text (only partial section of document) was pasted back into the doc, visible to all members.

Upon continuing to live-edit in the document, only one other member seemed to not be able to see the new text being added. All other members are believed to have normal behaviour, save one member. That member refreshed, and had visibility now into the new edits, but then it was decided to not trust the document live-editing and record subsequent notes offline.

[gerbrent]

Did you by chance see a Nextcloud notification saying "Changes could not be sent yet"?

I was actively note-taking during a meeting/call, so may not have noticed, though I typically do. That said, I did not notice any such message.

[gerbrent]

potential culprit worth investigating:

this scenario occurred while concurrently on an active 5 person Talk call. @gerbrent - the author of text that didn't propagate - residing on a different continent than the server, in a non-ideal internet connectivity situation. Thus latency, packet loss, bandwidth congestion are worth considering:

Ping times to server

• with no concurrent Talk call, i.e. low bandwidth demands:

--- ping statistics ---
2137 packets transmitted, 2137 received, 0% packet loss, time 2136113ms
rtt min/avg/max/mdev = 195.863/207.985/353.368/11.831 ms

Will attempt some pings in future calls/collaborative file editing in case that's helpful.

[juliusknorr]

Also @luka-nextcloud also encountered this with a flaky internet connection, unfortunately the browser console crashed last time when trying to obtain additional details.

[mejo-]

The problem might be that we currently don't resend steps after sendSteps() failed. We once had a retry mechanism in place, but I think it went away with d4e7eeb4.

We should probably do the following:

• Bring back a retry logic when sendSteps() failed.
• Make sure unsent steps are added back to this.#queue in #initiatveSending() of WebsocketPolyfill.js. Currently it doesn't happen because the passed getSendable() function never fails in my understanding.
• Give UI feedback if steps fail to be sent for a longer period, making it obvious that local changes are not synchronized to the server.

[mejo-]

A preliminary fix is in acf6c4e, but that needs further cleanup work.