Send reliable timestamp for when "Document changed in storage" conflicts happen

[pedropintosilva]

Describe the bug

It seems - in some cases - users are seeing the "Document changed in storage" conflict dialog even though no one else touched the file. This could be due to how richdocuments produces/compares the timestamp as it seems a cached value is been passed.

LastModifiedTime is already sent but its value - in some cases - is unreliable due to stale cached mtime after putContent. Probably best to ask storage layer again for fresh metadata instead of trusting that cached value. This might not fix the issue but it will fix for that situation and make further chasing easier to do.

Related: https://gerrit.collaboraoffice.com/c/online/+/4918 from @mmeeks

[mmeeks]

Hmm? not sure what the 'LastModifiedTime' thing means above - unless that's a Nextcloud / richdocuments detail but I'd like to see something like: (not compiled / tested) included

0001-Add-a-stamp-field-with-the-actual-mtime-to-the-json-.patch

[juliusknorr]

This was what Pedro and I thought was required to be added in the conflict case. It would be in sync with the naming used in other places, but we can pick your patch if stamp is what should be used from the Collabora Online side.

[mmeeks]

Ah - the name doesn't really matter; we will show whatever is in that JSON next to the COOLStatusCode to the user if they ask for that so do use whatever is most consistent :-)

[mmeeks]

Ah - but, of course - while we are here - if you'd like to go wild and lets us know who it was that did the last document upload and the size of that as well we can standardize that and present that more attractively in the dialog:

"JimBob up-loaded a new version of size <1023 bytes>" or whatever :-) it all helps the user I expect.

[pedropintosilva]

@elzody as discussed today, I'm pasting here our findings while having

• A collaborative editing session
• On a odp document
• Every user was editing in the web browser
• At least 2 users had the NC Sync client app running with that file synchronized
  • No Sync client error, file was also not opened locally, and there's just one 'sync' action in the detailed backlog (which seems to be right after the call/editing sessions) .

Oddly, ^ the gap seems quite big between the 2 timestamps but we do auto save quite regularly and that's what it makes that 50 minutes interesting.

Looking at the Nextcloud versions tab:

I wonder if there was some recent change that makes the versioning smarter via compacting/removing some of the versions in between or something that could explain those 2 timestamps.

[mmeeks]

Interestingly - in the same editing session on the same document between many users we also had:

Which has a timestamp mismatch vs. a minute old - that was around 10:15 AM. It is very curious that we don't see a lot more revisions here in the history - I would expect us to auto-save every 30 seconds or so if there is a change to the document (and there were lots of changes). So the gap from 52mins ago to 3 mins ago above is quite hard to explain.

[mmeeks]

This was what Pedro and I thought was required to be added in the conflict case. It would be in sync with the naming used in other places, but we can pick your patch if stamp is what should be used from the Collabora Online side.

Oh - that's great - if it is really that :-) nice work.

[mmeeks]

We also got subsequently one of these:

[Aveyron-RetD]

Maybe related to nextcloud/server#62204