D20040: Don't finish collection sync task too early

[Milian Wolff]

mwolff added inline comments.

INLINE COMMENTS

> dvratil wrote in resourcebase.cpp:136
> I would actually change this into an `assert()`, move it to the beginning of the function and try to find out what resource implementation calls `changeProcessed()` when not handling a ChangeReplay task.
> 
> The rules are that after successfully finishing a task resource implementation should
> 
> for retrieval task, call `ResourceBase::*retrievalDone()`/`ResourceBase::*retrieved()`
> for add/modify change replay task, call `ResourceBase::changeCommitted()`
> for remove change replay task, call `ResourceBase::changeProcessed()`
> for a custom task, call `ResourceBase::taskDone()`
> 
> In the first 3 cases, the methods will call `ResourceBase::taskDone()` internally themselves, possibly asynchronously. In any case, you must call `taskDone()` every time in order to trigger processing of a next task in the ResourceScheduler queue.

see the last comment here: https://bugs.kde.org/show_bug.cgi?id=403642

`agentbase.cpp`'s `collectionChanged` calls `changeProcessed` and then afterwards we get the `Akonadi::ResourceBasePrivate::changeCommittedResult` signal handler calling `changeProcessed` again. I naively (i.e. without digging deep) thought that this comes from the same change replay, and it should only call `taskDone` once, instead of twice like it is doing currently.

Is that enough info for you, or do you need more? How would you "find out what resource implementation" it is? This is always the imap resource which asserts. I can `rr record` this and send it to you, if you are interested?

REPOSITORY
  R165 Akonadi

REVISION DETAIL
  https://phabricator.kde.org/D20040

To: mwolff, dvratil, dfaure
Cc: kde-pim, dvasin, rodsevich, winterz, vkrause, mlaurent, knauss, dvratil
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20190325/69bfe9ed/attachment.html>