Comment 200 for bug 883459

Just for the records, I once tried to dig into the Akonadi code to find the bug.
I put my analysis to the other bug report, which is now set to a duplicate of this.
https://bugs.kde.org/show_bug.cgi?id=362398#c5
Just that it does not get lost, and I still think my findings are correct, here is it again:

I'm hunting the "duplicate mail bug" and I think I've found a bug in the Akonadi Server.
What happens here is the following:
- a resource adds a new mail item (id=3, collection=17)
- Akonadi sends "Item added" to the filter agent
- filter agent sends a "move" command to move item id=3 from collection=17 to collection=19
- Akonadi sends "item added" to the maildir resource (this is the first "added" message from the creation, so the
  item still has id=3 collection=17)
- I'd say in the Akonadi DB the collectionId of item=3 is now 19 (after the move)
- Now the maildir resource gets triggered by its internal file watcher and triggers a sync
- maildir gets called with retrieveItems and lists what it has on disc, which is the item (id=3) in the collection=17
- Akonadi receives this and inside Merge::parseStream() there the bad thing happens:
  It hits this "if" branch (server/src/handler/merge.cpp Line 301)
      // No item with such GID/RID exists, so call AkAppend::insert() and behave
      // like if this was a new item
 and INSERTS the item AGAIN into collection=17 with a new id=4
 Now I have the same mail item twice in the DB
 Since the maildir "itemsRetrieved" answer contains for the first time the RID, the newly inserted item gets this RID,
 and the previously intserted one id=3 does not and is left alone with a NULL RID

Someone more knowledgeable about the Akonadi internals should have a look, please.