Sync getting done too late

---

In SyncAdapterService.kt, onPerformSync(...) checks to see if you are already performing a sync of the requested account and authority. If so, you return without doing anything. The problem with this is that another process may be making many modifications to the calendar, and the sync will start on the first modification. So some modifications may occur after the affected events have already been synced. In that case the modifications will not get uploaded to the server until the next time DAVx5 does a sync. This isn’t disastrous, since the upload will eventually occur, but it isn’t what you say you do.

I think that the correct logic is to maintain for each Pair(authority, account) a flag which is initially false and set to true if another sync request has arrived during the sync. If in the finally clause you find that the flag is set, you clear it and do another sync instead of doing the removeAll().

I would offer a patch if it was Java code, but I’m not familiar enough with Kotlin to write code in it.

Seen with DAVx5 Version 2.1-ose built 1 Jan 2019

@rparkins Hello,

This check is only a work-around for some devices which start the same sync in parallel, which should not happen according to the docs.

The Android sync framework should be able to handle content changes after a sync has initiated and enqueue another sync.

1. Does this problem actually occur on your device? Can you provide verbose steps to reproduce (including server software, used calendar app etc.)? Please also post debug info and logs as described in [READ BEFORE POSTING] What’s required to diagnose a problem.
2. If it does occur: Is it correct that the sync is finished at the next regular sync interval?

I haven’t seen this occur: my comment was based on looking at the code. However if some devices can in fact start the same sync in parallel, the problem is real.

@rparkins said in Sync getting done too late:

However if some devices can in fact start the same sync in parallel, the problem is real.

Yes, but I will only make one level of workaround for these broken devices, not workarounds for the workarounds.

If you could provide information about the device and how this could happen, it would be interesting. Maybe it can be avoided by DAVx⁵, or the problem could be reported to the vendor.