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?

I think I found a root cause for the issue, I attached a patch to your bug report, please test it and let me know.