Skip to content

Fix endless sync loop with some remote iCal sources

Daniel Vrátil requested to merge work/dvratil/bko384309-ical-fix-endless-sync-loop into release/24.02

The sync in SingleFileResource implementations (iCal, vCard and MBox resources) is implemented in a little strange way for remote files:

  1. Akonadi (or someone) requests sync of the resource's collection
  2. The resource starts a download of the new file
  3. In the meantime, it syncs content of the current version of the file with Akonadi
  4. When the file is downloaded, hash of the file is compared with previous hash and if they differ, goto 1

Some remote sources (e.g. Google Calendar) generate the iCal on-demand and as such the file always contains a different DTSTAMP. Thus, whenever the iCal resource completes the download, the hash will always differ compared to the previous one, and so it will again re-schedule sync over and over. While the data are actually available in Akonadi and to the user, it causes a high CPU load as the iCal is constantly being re-parsed, Akonadi database update, the Indexing agent is triggered over and over again. And the bigger the calendar, the worse it is.

This fix changes the behavior by downloading the file, running the parser (iCal/vCard/mbox/...) and after that performing a regular sync, so basically:

  1. Akonadi (or someone) requests sync of the resource's collection
  2. The resource starts a download of the new file
  3. When the file is downloaded, the resource syncs the content of the file with Akonadi.

I have opted for using QPromise+QFuture combo to perform the async chaining of download->sync. It's the only solution that requires the last amount of code refactoring and reorganization in order to properly sequence the operations. This would be the perfect place for using coroutines, but I don't want to introduce coroutines as part of a regular bugfix. I might do an experimental port at some point later.

BUG: 384309 FIXED-IN: 24.02.1

Merge request reports