Open Document Timeout

[alexknop]

Problem:

When offline and attempting to open a document via the Document Provider, the wait time is excessive.

CheckEtagRemoteOperation is reporting ETAG_CHANGED when the connection times out to the server, thus triggering needsDownload.

Instead, if the file is saved offline and the etag cannot be read from the server, there is no need for download.

Solution:

Implemented shorter timeouts than the default, which would take longer than is necessary.

If the etag has changed and we have a connection to the server, then result's data will be populated.
We now check whether this data exists.
If data returns null (which results from a timeout), then we return false. This skips the unnecessary download attempt.

Fixes #14478

[github-actions]

Hello there,
Thank you so much for taking the time and effort to create a pull request to our Nextcloud project.

We hope that the review process is going smooth and is helpful for you. We want to ensure your pull request is reviewed to your satisfaction. If you have a moment, our community management team would very much appreciate your feedback on your experience with this PR review process.

Your feedback is valuable to us as we continuously strive to improve our community developer experience. Please take a moment to complete our short survey by clicking on the following link: https://cloud.nextcloud.com/apps/forms/s/i9Ago4EQRZ7TWxjfmeEpPkf6

Thank you for contributing to Nextcloud and we hope to hear from you soon!

(If you believe you should not receive this message, you can add yourself to the blocklist.)

[tobiasKaminsky]

Hi,

I'd like to ask to apologize for being late at this PR.
I will check it now.

[tobiasKaminsky]

Timeout of 1s might lead to false positive errors?

On Files app we know if the app is offline, so maybe we can re-use this?
E.g. we have NetworkChangeReceiver

What do you think?

[alexknop]

I do not see why not, but in terms of implementing I do not have enough knowledge of this app's architecture.
It seems like a good check to run and act on accordingly prior to determining whether to run hasServerChange.

I was simply bug fixing in noticing offline files take an egregious amount of time to load, and noticing the return value for the eTAG played a role in it. I do think timeouts can be reduced, in this age 1 second is a long time to reach your server, but I understand wanting a bit of a safeguard. I thought this function also retried a few times prior to returning a value, which is a safeguard in itself.

Hope this helps, but apologies for not being able to carry this idea out.