This is kinda dangerous: if the RIDs are duplicated, we cannot know if all the matching Items are just multiple instance of the same Item: they can be two completely different Items, accidentally having the same RID stored in the DB. In such a situation, this patch will correctly update the content of the rightful RID owner, but destroy the content of the Item with the broken RID.

How about only merging with candidates that have the same size? This problem is almost exclusive to emails, and emails don't generally change their size.

The problem is, in this case, with the existing code, the only way to get akonadi working again would be dropping the cache in akonadiconsole, and then redownloading everything from the server, which means we would only have one of the RIDs. If we could make sure than excess RIDs are removed during normal syncs, that would work too as syncs are automatically triggered if there is a duplicate like this because the number of messages doesn't match. This change just makes things keep working until such a correction is made.

As for ignoring cases where size doesn't match... Then what? Akonadi would still be completely frozen if chose to fail here, and would need to have the cache cleared to do anything. This is a hard error state, akonadi stops working if we don't do finish the merge, failing leads to a brick state for most users.