ItemSync: skip handling remote items if local changes failed

Authored by dfaure on Apr 4 2019, 6:56 AM.



The infamous "Multiple merge candidates" error would still leave ItemSync
in a forever-stuck state when mRemoteItemsQueue was not empty.

Reproduced by adding a unittest that calls setFullSyncItems (with
a duplicate item), while the existing unittest for a duplicate item
was callling setIncrementalSyncItems().

I barely understand what I'm doing, please review carefully.

Test Plan

Unittest passes.

Diff Detail

R165 Akonadi
No Linters Available
No Unit Test Coverage
Build Status
Buildable 10570
Build 10588: arc lint + arc unit
dfaure created this revision.Apr 4 2019, 6:56 AM
Restricted Application added a project: KDE PIM. · View Herald TranscriptApr 4 2019, 6:56 AM
dfaure requested review of this revision.Apr 4 2019, 6:56 AM
asn added a subscriber: asn.Apr 4 2019, 7:12 AM

:-( This is getting awfully convoluted, I'm having a really hard time keeping track of the state.

I wonder if it wouldn't be easier to simply finish the job in checkDone() (which gets called from everywhere) when there's an error and adjust ResourceBase to stop feeding the ItemSync job when it is in an error state. That should make all this error-handling madness easier. I'll look at this at the sprint.

dfaure updated this revision to Diff 55649.Apr 7 2019, 11:08 AM

update comment so it makes more sense

dfaure updated this revision to Diff 55654.Apr 7 2019, 12:07 PM

setError not needed, done by slotResult

dvratil accepted this revision.Apr 7 2019, 12:30 PM


This revision is now accepted and ready to land.Apr 7 2019, 12:30 PM
dfaure closed this revision.Apr 7 2019, 1:05 PM