Fix 409 (Conflict) causes and handling

[max-nextcloud]

We used to have 409 responses when the client was not in sync with the server state. But with yjs we can now always apply updates as long as they belong to the same session. Still some users are reporting changes being lost while editing with > 10 people in text. 409 Responses are showing in their logs.

Sync requests

Sync requests can trigger 409 responses if the underlying files etag and mtime differ from the document records values. This will happen if a file is saved through a different mechanism such as desktop client sync or restoring an old version.

Client side handling

The client will see 409 responses to sync requests and process them as normal responses. This is important so the sync mechnism continues working even if there has been a different update to the file. The 409 will 'only' cause the editor to display the conflict screen with both options to pick from. One problem with the current approach is that every sync request that responds with a 409 will include the complete local file. As the sync continues even on conflicts that is actually quite a bit of overhead.

Could they cause removal of content added by the client or another client?

Currently I don't see how.

Save requests

✅ TODO

• [x] create follow up issue for smoother handling of expired sessions
• [ ] look into save requests

[max-nextcloud]

Recovering a file from old versions triggers 409 requests right now.

MOVE remote.php/dav/versions/max/versions/$FILE_ID/$TIMESTAMP

[juliusknorr]

https://github.com/nextcloud/text/issues/5473 may also be related?

[max-nextcloud]

#6918 was also really helpful in reducing the relevance here. Now if i open a text file, make no changes and open the sidebar a revert to a previous version will not cause a conflict view anymore. Instead it shows that the editing session expired and asks the user to reload.

Next step would be making that experience more smooth.