File doesn't unlock in the website after editing

[markrosan8]

I am using a custom office docs editor that plugs into the wopi server. Opencloud rolling latest version.

I noticed that sometimes when I close a file, even though the editor logs show unlock request, the web ui doesn't unlock the file until I manually refresh the page. The behavior is inconsistent, sometimes it will unlock nearly instantaneously, and sometimes it requires manual page reload.

I also checked this with onlyoffice in place of my custom docs editor, and same issue occurs. So it looks like the web page is not reading the file lock status correctly at times.

The issue is not present if using the built in collabora editor.

[micbar]

The icons are updated via SSE. Check your browser console for errors.

These are basically long polling connections. Most reverse proxies are killing these connections after 60 sec. So you need to check your reverse proxy connection.

[markrosan8]

You’re right, there is a sse error in the console. But this seems to happen even within 60 seconds.

My proxy is just the built in traefik in opencloud compose. Is there some config here I should be aware of?

Or perhaps there is a more resilient way to check for file lock status?

[micbar]

Just to be clear: that only affects the UI. The file is unlocked instantly.

What is the sse error?

[markrosan8]

No, it's not just cosmetic, it prevents rename, delete, other operations until the lock is resolved.

Error is "Failed to load resource: the network connection was lost - https://domain.com/ocs/v2.php/apps/notifications/api/v1/notifications/sse"

[markrosan8]

@micbar this seems to be a traefik configuration issue.

Setting flush interval to -1 makes file unlock after close much more reliable:

"opencloud:
labels:
- "traefik.http.services.opencloud.loadbalancer.responseforwarding.flushinterval=-1"

There may be other traefik config options to ensure sse is delivered reliably.

[smoothscholar]

@markrosan8 I am facing the same issues, but also on collabora sometimes. Not sure why it doesn't happen to you with collabora

Flush interval helps, and I have also enabled the sse keep alive. But if I close my laptop, or the network cuts out, the connection takes time to reset, and in the meantime the file lock error occurs

@micbar I wonder, does the page reestablish the SSE immediately after network reconnection, and does it check for missed events? Or maybe the simplest thing is to just drop SSE and poll the server every second or so until all file locks disappear.

This can really be quite annoying when you're working on a bunch of documents and you have to reload the page and disrupt the flow.

[micbar]

But if I close my laptop, or the network cuts out, the connection takes time to reset, and in the meantime the file lock error occurs

I see. From my POV, resuming "everything" in the Web Client after closing the laptop is a real challenge.

But i agree that the SSE client should reconnect.

@kulmann @JammingBen Is that correct? Can we verify or improve that?

[JammingBen]

The SSE client has a mechanism to reconnect on error (wich includes network issues). It doesn't happen instantly though, it's 30 seconds (+ some random offset to balance load on the server) after receiving the error. I think you already noticed this:

But if I close my laptop, or the network cuts out, the connection takes time to reset, and in the meantime the file lock error occurs

We can't just instantly reconnect because the error might have been caused by the server, which would lead to every client reconnecting at the same time. That's what the random offset is for.

I guess the client needs to somehow detect if the connection was cut by the client (e.g due to network issues) and then reconnect to SSE immediately and/or do a manual poll. When doing the latter, I prefer to only poll once, assuming the SSE connection will be up and running again shortly after.

[smoothscholar]

@micbar @JammingBen tbh it seems like SSE is fragile and needs a lot of things to go right. Maybe it is easier and more reliable to have an automatic poll for file status if there is a locked file, until all file are unlocked, with a configurable interval.

Client just needs to make small file lock query with current directory, and server returns ID of all locked files in that directory, which client updates. No need to worry about proxy buffering or anything else.

[micbar]

@smoothscholar I do not think that SSE is the issue here, generally reconnecting a Web client after the laptop has been closed is taking some time (30s). Polling would not solve this issue. The Web Client doesn't rely on SSE only for the locks. Every normal request driven directory listing also checks for the locks.

@JammingBen Any chance to improve reconnect behavior in general?

[smoothscholar]

@micbar @JammingBen I did some more digging into this issue, and I think its not caused by network disconnect issue alone.

I opened and closed a doc file many times to reproduce the error. I noticed that whenever the lock persisted, the console logs actually showed the SSE file unlock. The SSE was being received fine, but there is an occasional error in actually reading or acting on that file unlock event in the web app/UI.

[smoothscholar]