Source document is not refreshed if no changes have been made made in the coediting session

raphaelbadawi commented 3 weeks ago

This issue is unique.

[X] I have used the search tool and did not find an issue describing my bug.

Operating System of DocumentServer

Linux (RPM package)

Version information

8.1.1

Expected Behavior

A coediting session has been created on a document. The document has been unlocked for some reasons (e.g. coeditors offline, everybody has "left"). A new version of the document has been dropped in the meantime to the document repo. Editors go back to the coediting session, bringing back the same session key. The document is refreshed, the last version is appearing.

Actual Behavior

If no changes has been made yet in the coediting session, the source document will not be refreshed. It will just bring back the outdated version ot the document.

Reproduction Steps

Create a coediting session on a document
Do not make changes on the document
Leave the coediting session
Upload a new version of the document on the document repo (the document served by the document URL is changed)
Go back to the session (the session key must be the same)
The source document is not refreshed
You may also reproduce this without explictly leaving the document, by having the editors offline for a moment

Additional information

No response

igwyd commented 3 weeks ago

Hello @raphaelbadawi, this is expected behavior. If there are no changes, then there is no need to create a new version of the document. We have a request #66751 to create new versions of the document without changes forcibly using forcesave option, Will this option suit you?

raphaelbadawi commented 3 weeks ago

Hello,

I believe there was a bit of a misunderstanding here. The issue is not about creating new version of the document. It's about being able to invalidate source document caching (the document initially fetched from the document.url).

The case is when we bring back a coediting session (a session with the same document.key exists, a cache folder matching the document.key exists on the server). And this is a session where no changes were made yet. But the source document has been overwritten - not by OnlyOffice, but for example by FTP drop or whatever may overwrite the document. And in this case, it's not possible to invalidate the cache so OO would download the source document again.

igwyd commented 2 weeks ago

Unfortunately, I don't understand yet how to repeat this. Could you describe the scenario in more detail? In integration for example, with nextcloud or some other?

igwyd commented 2 weeks ago

If I understand you correctly, that's the right behavior, too. This is the way it should be and is implemented in our integrations.

after upload the key of the document in the repository is changed. Any new opening of the file falls into the new key
sends a callbackUrl request when the editor connection is restored
if the integrator sees that not the latest version of the file was opened for editing, it sends the drop command.

Here's some documentation on how it works https://api.onlyoffice.com/editors/howitworks

raphaelbadawi commented 2 weeks ago

Hello there,

Thanks for the preliminary investigation.

I'm using OnlyOffice with Alfresco, using the official connector.

So yes, I open a session with a document key, let's say for convenience that the key value is "fizzbuzz". The internet connection is lost before any change is made. All users are disconnected from the session. In the meantime the content of the source document is changed but the key remains the same: "fizzbuzz". When going back to the coediting session with the key "fizzbuzz", the document is not retrieved from the URL, but from the document server cache, and is outdated.

Hope is a bit clearer like this.

ONLYOFFICE / onlyoffice-alfresco