Editor reports connection issues and blocks editing

[mejo-]

Describe the bug
After being in a editing session for some time, the editor reports "The document could not be loaded. Please check your internet connection."

Looking at the network requests, all requests went through (no 4xx or 5xx) and no error log in the console either.

It seems though like hasConnectionError in Editor.vue gets set to true somehow in onChange(), triggered by _fetchSteps() from the PollingBackend.

Screenshots

Server details:

• Nextcloud version: 33 dev and 32.0.1-rc2 at least

[juliusknorr]

I had seen it once but unable to trigger it again. For now I have a few windows open with a conditional breakpoint here:

[juliusknorr]

[mejo-]

I was also able to catch the error by adding a watcher on hasConnectionIssue in Editor.vue. The change on hasConnectionIssue seems to be triggered by this line:

text/src/components/Editor.vue

Line 531 in 177bbb9

this.document = document

After adding a conditional breakpoint just like Julius did above, it looks like this:

and

I wonder whether the debugger runs wild because it resolves document here as the global Window document property which is also accessible directly via document.

Maybe we indeed should rename local variables document if they're not instance variables (i.e. this.document).

[juliusknorr]

Looks like a debugger / source map issue yes.

Maybe also interesting in the trace where close is called for me:

[theLockesmith]

This seems to be correlated with POST errors upon opening the file happening every few seconds.

[mejo-]

Just now my breakpoint here stopped before hasConnectionIssues was altered. And indeed the last sync requests before happened only every 30 seconds. So probably they got throttled after no changes happened for some time.

Since messageReconnectTimeout in y-websocket.js is 30 seconds as well, I suspect a timing issue. When the sync requests happen only every 30 seconds and one of them takes a bit longer, the linked code path is touched and closes the "websocket connection" (which is no real websocket connection in our case).

[mejo-]

It's easy to reproduce by setting messageReconnectTimeout in y-websocket.js to 4000.

[max-nextcloud]

What comes to my mind:

• The websocket will close if it does not receive awareness updates in 30 seconds. y-websocket sends awareness updates itself every 15 seconds. So not seeing any for 30 makes it believe the connection is broken.
• fix(sync): handle empty push requests #7702
  Maybe this is a side effect? Before we did not respond with steps to pushes that only contained an awareness message. Now we send the steps that arrived in the meantime. This means that the steps will not be included in the next sync response. So the polling backend is more likely to not receive any steps and think there is no activity going on.
• Afaik we also do not send the latest awareness messages in a push response but only in a sync response. Otherwise we'd at least see our own awareness message bounce back like updates do.

[mejo-]

@max-nextcloud I guess the problem is that FETCH_INTERVAL_INVISIBLE in PollingBackend and messageReconnectTimeout in y-websocket are both 30 seconds. So probably we should either lower the former or raise the latter by five seconds, what do you think?

[max-nextcloud]

what do you think?

@mejo- sounds good. I'd shorten the FETCH_INTERVAL_INVISIBLE - but both seem fine.