Page MenuHomePhorge

Make sure we always respond with the latest sync key

Authored by mollekopf on Jan 25 2024, 1:27 PM.
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



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

rS syncroton
Lint Not Applicable
Tests Not Applicable

Event Timeline

mollekopf created this revision.
machniak added inline comments.

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