Page MenuHomePhorge

Make sure we always respond with the latest sync key
ClosedPublic

Authored by mollekopf on Jan 25 2024, 1:27 PM.
Tags
None
Referenced Files
F11282322: D4640.diff
Mon, Mar 4, 7:02 AM
Unknown Object (File)
Thu, Feb 22, 4:55 PM
Unknown Object (File)
Tue, Feb 20, 8:42 PM
Unknown Object (File)
Tue, Feb 20, 5:23 PM
Unknown Object (File)
Sun, Feb 18, 6:15 PM
Unknown Object (File)
Sun, Feb 18, 5:25 PM
Unknown Object (File)
Sun, Feb 18, 5:41 AM
Unknown Object (File)
Tue, Feb 13, 1:22 AM
Subscribers

Details

Summary

Previously if a client e.g. sent a modification resulting in syncKey=4,
but then sent another Sync with syncKey=3, the server would just respond
with syncKey=3 instead of 4, which in Outlooks case resulted in the
client resending the modification that lead to syncKey=4 over and over.

Diff Detail

Repository
rS syncroton
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

mollekopf created this revision.
machniak added inline comments.
lib/ext/Syncroton/Command/Sync.php
971

Let's rename _next to counterNext.

I think resending data will be needed, especially if there are server modifications. We don't know why client sends the previous SyncKey, maybe it just lost the previous response. If we don't send what has been changed we're out of sync.

We'll have to double check, but I think the only this we're not sending is the client modifications from the previous sync from the same client.

  • Client send modification with synckey=3
  • Server responds with synckey=4
  • Client sends emtpy sync with synckey=3 (instead of 4)
  • Server now responds with synckey=4, but doesn't report the modification again.

Renamed the member variable

This revision is now accepted and ready to land.Jan 26 2024, 9:32 AM