Bug 338658

Sorry, I intended to specify "...on both of the GMail accounts I've set up with *IMAP*"

I have the problem into Kubuntu 14.04, too.

Since my previous system upgrade of Debian Testing (Jessie) on Friday, I'm seeing this too. Versions are the same as the original bug reporter.

Specifically, it's when syncing my Google IMAP "All Mail" folder, which still shows several unread messages, despite me having read them in another folder. Before this most recent update, the "unread" messages would eventually disappear from my All Mail folder on their own (ie. at the next automatic sync of that folder).

Agreed: I have also noticed that whereas previously when mail was marked as Read in one folder, it would eventually be marked as Read in another, this no longer happens. I'm sure that's no coincidence :p

I can confirm both problems on opensuse, same versions.

I *just* started seeing this in Kontact 4.14 with kdepim-runtime pinned to 4.13.3 after having some problems with 4.14 of kdepim-runtime. I am *not* using Gmail, but IMAP against a courier-imap server. I was having some issues with messages reappearing after deletion or moving our of my inbox and after three or four times repeating the delete/move, I now get this message when viewing my inbox.

I can confirm this bug in Kubuntu 14.04 using kdepim-runtime 4.14.0 and akonadi server 1.12.91.

My e-mail account is NOT a Gmail one. So the problem is not Gmail exclusive.

Same here: Akonadi 1.2.91 IMAP resource (server is dovecot) & kmail from 4.14.0 and 4.14.1

Maybe related:  Sometimes this resource stops syncing, e.g. at 54 or 75% and hangs.  I've to stop/start akonadi to get new mail again.

Achim

Yes, I'm getting the same thing: the imap resources get stuck, and I have to "killall axonadi_imap_resource", and then restart them via the Akonadi Console in order to un-stick them. I've pretty much abandoned KMail for now as I can't use it for more than 10mins before it gets stuck. I've had to fall back to the GMail web app until this is resolved.

FWIW a head up info:  developers discussing the 'multiple merge candidats' on kde-pim@kde.org.

 http://lists.kde.org/?l=kde-pim&m=141241776131472&w=2

So despite the silence here, there's aktivity to get the bug fixed.

Achim

*** This bug has been confirmed by popular vote. ***

I experience the same error which results in a burning CPU for (a) minute(s), increased data usage, inresponsive KMail (as the full mail boxes have to be retrieved).

Affected IMAP folders:
 - GMail "All Mail" (possible changes: removed message (to Trash), read/unread state, Archive (move to All Mail))
 - Dovecot mail server: 12k mailing list archive, 7k mailing list archive. Read/unread status, possibly KMail auto-archiving messages older than X days.

Any workaround/fix for this productivity killer? I have been holding back akonadi/kdepim updates on Arch Linux since September, but recently boost updated and I couldn't keep the old combination working anymore.

Sadly, I've had to abandon KMail for the time being, as either this issue or something related to it is causing the Akonadi agents for my GMail IMAP to stop responding. I can retrieve e-mail if I kill and restart them, but they only last for a couple of minutes before freezing up again. I've had to resort to the GMail web interface for several months now :(

Same boat as all of you. I hate the Gmail web interface (even Inbox). I have multiple IMAP clients going (iPhone, iPad, Mail on Mac) and those work, but KMail almost never does as of late. Only recently it started to get really bad and basically always fails to sync the 'All Mail' directory. This stops everything from working pretty much. It gets to 99% and stays there forever. Restarting the Akonadi server does not help very much. I have one Gmail account with emails dating back to 2004, other IMAP clients have no problem viewing that account's 'All Mail' folder back to the first entry.

Continuously, my accounts in Akonadi Console say 'Connection established.' as opposed to 'Ready'. This is completely random. Right-clicking on that one and choosing 'Restart agent' does nothing. Neither does Toggle offline/online.

I tried to set everything to live mode as well, where content is downloaded on an as-needed basis. This has only resulted in me getting the 'Retrieving Folder Contents' message, and it never goes away.

Really not sure what to do. KMail was great in KDE 3. I've tried to live with Akonadi integration in KDE 4 and even tuned my PostgreSQL server for it. Even with debug tools like Akonadi Console and enabling the PostgreSQL general log, I cannot tell what the problem is. Every once in a while I see that Google denied the connection, and that makes sense. But my other IMAP clients do not generally get this issue and they even have check intervals of 30 minutes.

I really hope this is figured out. Although KMail lacks a 'Archive' feature like in Mail.app on Mac, it still is my favourite e-mail client on Linux.

I'm also getting this. I'm not using GMail, but Outlook Web App.

I confirm the issue on Archlinux with Akonadi 1.13.0, though it is a new issue to me.

Same here with Fedora 21, and akonadi-1.13.0-8.

Same here observed with Novell Groupwise server. Gentoo, kmail 4.14.3, akonadi 1.13.0

I get this using Kontact 4.14.4, but seen it since several updates.

I get this against my work e-mail against Exchange imap server. The trigger seems to be when I delete some messages from my Android phone, then delete some on my desktop via KMail.

Emptying the trash folder on the exchange account seems to clear this up, until the next time I mix deletes. I notice that once I empty the trash, the messages stop, but previously deleted emails show up in the trash folder.

Anybody knows what is the status of this one? There are no new mails in the linked mailing list thread.

No idea, I have meanwhile tried Thunderbird and am now using mutt. All of the three mail clients have their issues.

I have at least figured out how to fix the database in order to get directories syncing again using the Akonadi Console. (Disclaimer: this worked for me, may not work for you, you might lose data if you aren't careful, etc.)

First I searched to find the duplicate keys using the "DB Console" tab with the following query:

SELECT pimitemtable.*, collectiontable.name FROM pimitemtable
INNER JOIN pimitemtable dup ON pimitemtable.id != dup.id and pimitemtable.remoteId = dup.remoteId and pimitemtable.collectionId = dup.collectionId
INNER JOIN collectiontable ON pimitemtable.collectionId = collectiontable.id
ORDER by pimitemtable.remoteId

Then I looked for the items specifically in the folders that I knew were failing to sync with the "Multiple merge candidates, aborting" error, then used the Id to track down one of the duplicate items in the "Browser" tab and then deleted it there from the context menu. (There are still others with duplicate ids, but I have not deleted those since they don't appear to be causing any problems.) I then restarted the akonadi server, and then reloaded the folder in KMail and voila, the folder now synchronises successfully.

Still affected with akonadi 1.13.0-3, workaround by Paul worked for me.

also affected

Paul: your query sadly didnt work for me :-( 

my versions are: (OpenSuse 13.2)
akonadi-runtime-1.13.0-2.2.3.x86_64
akonadi-4.14.5-12.5.x86_64

Also affected.

Will dig this out (have to) and will find out the retard who wrote this piece of shit code.

The root cause is that if you move an e-mail (or any node basically) into a folder, which already has the same identical e-mail/node, this error pops up.

So instead of doing the only sane thing imaginable (i.e. seeing that that the e-mails/nodes are identical copies) this piece of shit errors out without even giving the user an idea where problem is. Whoever wrote this should never touch a keyboard again.

the heartbleed-guy didit ;-)

(In reply to Christoph from comment #27)
> the heartbleed-guy didit ;-)

Sorry, but that's just ignorant. Even with the smiley.

I just found a way to reproduce this bug.  I use GMail and have filters in there that automatically add tags to email, but still leave that email in the inbox.  If I then use KMail to sort through my inbox, I sometimes end up moving the message to the folder corresponding to the tag that is already present.
This seems to toggle the issue of having multiple merge candidates, GMail has the same id for the email, while KMail / Akonadi think they are two different IDs who just happen to share the same remote ID.
I am not an IMAP / Akonadi expert, but it seems to me that these cases could be merged relatively easily.  Both messages have the same remote ID, and they should not be different in the views of the Akonadi cache.

einar77 on IRC helped me to go around this problem by resetting Akonadi cache:
akonadiconsole -> browser -> right click on folder / account, "clear akonadi cache", but this will prompt a full download again of the mail

The above suggestion is not a solution for the problem, but at least it mitigates the problem by providing a manual fix.

I'm rather shocked that a "GRAVE" bug that has been confirmed and assigned seems to be completely ignored. Would the assignee please update the bug so that all those of us interested can be apprised of progress made or help needed.

Workaround: if you need to not be disturbed by errors issued when checking emails automatically every few minutes, go to offline mode in kmail. Then it laments only once. (sigh)

I have the same problem - used the fix suggested by  Paul Eggleton and it worked. I can't understand how this issue can be reported for over a year without single comment by any developer.

This really doesn't show KDE team in the best light, and the fix seems to be quite trivial.

I love KDE, so these kinds of thing are quite a disappointing.

OK, I was too quick to assume the problem was fixed  - the workaround worked for a single instance of the problem but it is occurring again semi-regularly.

Kontact
Version 4.14.7

I'm using filters, it's possible that the filter engine copies the message to another folder but fails to delete it from the original one ... just guessing here, I'm willing to debug the problem with a developer, is anybody willing to take this on?

Thanks

Paul, thanks to your manual I just fixed the issue on my system. Never received an error message, kmail just stopped syncing.

Time to test this bug on kdepim-5, who gets it first?

I'm on it for like 2 weeks now and this problem haven't happened so far.

But that doesn't mean it's gone due to random occurring :(

It's not random, read comment #29 how to reproduce.

If I understand correctly - I've just move message from GMail inbox to the tag folder. Now I have 2 identical message in the tag folder and no error message was shown.

Hi all,

fix has been pushed to old KDE/4.14 branches of kdepimlibs and kdepim-runtime as well as Applications/15.08 branches (the current KF5-based stable branches) and master. KDE/4.14 won't see any more releases, but if your distribution does not ship KDE Applications 15.08 yet, please poke them to get following commits:

kdepimlibs.git: 442961918d8f3d9ff94fd4593c9b09d1e89d6bc0
kdepimlibs.giit: d8b5da7bb16bfd3652e83200d851af3a21816469
kdepim-runtime.git: 93a2baac05a325b688aea2cc12d9714d6b186f69

If you distribution ships KDE Applications 15.08 the update will arrive as part of KDE Applications 15.08.2 (unfortunately we missed the 15.08.1 tagging). You can ask your distributions to add following patches:

kdepimlibs.git: 43d5659a88a6ebb3423c6228986f0bd1e1f496f7
kdepimlibs.git: ffa20e75f388bfa87530e113641f0830a5a58ec4
kdepim-runtime:git 038c604aba0cac22275e03c3497672cd254c2568

I'm really sorry it took so long to pin this issue down and fix it.

Hi Daniel,

that's great news!
It's good to see this issue finally sorted out. Thanks to your pointers, the Gentoo Devs already integrated the fixes for KDE Applications 15.08 and the patches for KDE 4.14.10 are soon to come.

Thanks for caring!

Thank you very much, I've added ppa:kubuntu-ci/stable in hopes it will be fixed there first, so I'll observe for a while whether the error stops ;)

Thank you again, it's great to see bugs being fixed.

Hi Daniel,

Thank you very much!

I only now discovered the error message after wondering for 3 months why I got no updates, and thanks to you searching for the solution found the best answer: “fixed two weeks ago, will be included in the next release”.

Best wishes,
Arne

Nah.

Just upgraded to 15.08.2 but still get the following message:
AgentBase(akonadi_imap_resource_1): Multiple merge candidates, aborting

Have you tried readding the IMAP accounts to kmail?
I had to do this before the issue was gone.

Happens to me on akonadi version 15.12.1. Also recreated the IMAP resources week or two ago.

I've kind of found a workaround for this issue and I've blogged about it here: http://ovidiu.geekaliens.com/en/2016/01/05/multiple-merge-candidates-aborting-workaround/

I hope it helps.

Yes i was already thinking about linking it here. The issue is that i got this failure mostly on MS Exchange IMAP. Cos i have 2 gmail accounts and one MS Exchange. All IMAP.
On the MS Exchange i have multiple folders + kmail filtering(moving from Inbox to folder)
Im not sure how to move it on MS Exchange. Wil try to find out.

(In reply to Paul Eggleton from comment #22)
> I have at least figured out how to fix the database in order to get
> directories syncing again using the Akonadi Console. (Disclaimer: this
> worked for me, may not work for you, you might lose data if you aren't
> careful, etc.)
> 
> First I searched to find the duplicate keys using the "DB Console" tab with
> the following query:
> 
> SELECT pimitemtable.*, collectiontable.name FROM pimitemtable
> INNER JOIN pimitemtable dup ON pimitemtable.id != dup.id and
> pimitemtable.remoteId = dup.remoteId and pimitemtable.collectionId =
> dup.collectionId
> INNER JOIN collectiontable ON pimitemtable.collectionId = collectiontable.id
> ORDER by pimitemtable.remoteId
> 
> Then I looked for the items specifically in the folders that I knew were
> failing to sync with the "Multiple merge candidates, aborting" error, then
> used the Id to track down one of the duplicate items in the "Browser" tab
> and then deleted it there from the context menu. (There are still others
> with duplicate ids, but I have not deleted those since they don't appear to
> be causing any problems.) I then restarted the akonadi server, and then
> reloaded the folder in KMail and voila, the folder now synchronises
> successfully.

This does work in Kmail5.  Has anyone tried the remove duplicate email option in the folder?

(In reply to Ovidiu-Florin BOGDAN from comment #46)
> I've kind of found a workaround for this issue and I've blogged about it
> here:
> http://ovidiu.geekaliens.com/en/2016/01/05/multiple-merge-candidates-
> aborting-workaround/
> 
> I hope it helps.

This also works in Kmail5.  Paul Eggleton posted a work around using Akonadiconsole which works as well.  I'll ask the same question here as well.  Does the remove duplicate emails function in "folders" accomplish the same result?

I haven't seen this question asked (may have missed it) but, does filtering in Kmail conflict with filtering in Gmail?

The only fix for the "Multiple merge candidates" error is to run Akonadi Console, go to "Browser" tab, right-click the broken folder and select "Clear Akonadi cache". Then restart Akonadi and it will re-fetch content of the broken folder from the IMAP server.

(In reply to Daniel Vrátil from comment #50)
> The only fix for the "Multiple merge candidates" error is to run Akonadi
> Console, go to "Browser" tab, right-click the broken folder and select
> "Clear Akonadi cache". Then restart Akonadi and it will re-fetch content of
> the broken folder from the IMAP server.

Dan, if I've been working on the folder in the meantime locally, in particular moving e-mails into that folder, are these mails lost then?

I'm using Kubuntu 16.04 (beta) and the neon repository: KMail 5.1.1, Akonadi 15.12.1 and Frameworks 5.21

If I by mistake leave KMail running at work when I go home and start KMail at home I get this problem 9 times out of 10 when I get back to work. I use local filtering both at work and at home.

I guess the problem is that the filtering is moving the message to the filtered folder twice because the move is not atomic.

It would be better to show a dialog explaining the problem and ask the user what version to use than just failing if we don't want to potentially destroy data. If I don't enable the more detailed progress information I don't even get informed about the failure.

I've been wrestling with akonadi during the past months (15.12.0 - 16.04.1) using `akonadictl fsck` and `akonadictl restart` whenever I clearly knew there really was new mail on the (gmail) server while kmail kept silent - which could happen several times a day. Today, by chance I've met an old friend again, "Multiple merge candidates, aborting", so maybe it had been that problem all the time. Above SQL query though revealed _a lot_ of duplicates, so maybe it is the result of all the times akonadi goes on a 'several thousand new mails in random subfolder' frenzy (also can happen a couple o' times a day). Either way, I wouldn't delete them one by one, so I came up with another SQL statement:

DELETE FROM pimitemtable
WHERE pimitemtable.id in (
  SELECT id
  FROM pimitemtable
  LEFT OUTER JOIN (
    SELECT MIN(pimitemtable.id) as RowId, pimitemtable.remoteId, pimitemtable.collectionId
    FROM pimitemtable
    GROUP by pimitemtable.remoteId, pimitemtable.collectionId
  ) as KeepRows ON pimitemtable.id = KeepRows.RowId
  WHERE KeepRows.RowId IS NULL
)


Beware, this might kill n kittens if you ran it on your system.

For me mysql complained about "You can't specify target for update in FROM clause".  Wrapping things into another layer of SELECT did the trick:

DELETE FROM pimitemtable WHERE pimitemtable.id in (
  SELECT id FROM (
    SELECT id FROM pimitemtable
    LEFT OUTER JOIN (
      SELECT MIN(pimitemtable.id) as RowId, pimitemtable.remoteId, pimitemtable.collectionId FROM pimitemtable GROUP by pimitemtable.remoteId, pimitemtable.collectionId )
    as KeepRows ON pimitemtable.id = KeepRows.RowId
    WHERE KeepRows.RowId IS NULL)
  AS foo)

(In reply to Stephan Diestelhorst from comment #54)
> For me mysql complained about "You can't specify target for update in FROM clause".
Yep, my above solution was done with PostgreSQL.

And today I had to use it again. 6 fresh duplicates after 16.04.2 had been really working well for a week or two.

*** Bug 355498 has been marked as a duplicate of this bug. ***

This bug is affecting all my imap accounts both at home and at work to the point of making kmail useless. 

New duplicates often appear after after I move mails between folders.

*** Bug 335776 has been marked as a duplicate of this bug. ***

is this ever going to get fixed? Reporting bugs to KDE is heartbreaking. You spend time tracking things down, file a report which you might as well have sent to /dev/null.

Git commit 66b87061f523e392236d73dea668ddf6772eb545 by Daniel Vrátil.
Committed on 07/01/2017 at 11:07.
Pushed by dvratil into branch 'Applications/16.12'.

Reset Item RID on both inter- and intra-resource MOVE

This should significantly help to mitigate the "Multiple Merge
Candidates" error during sync. One of the major reasons why MMC
happens is when user moves an Item belonging to an IMAP resource
to another Collection. On IMAP RID corresponds to IMAP UID. If
you move such an Item into another Collection which has IMAP
UIDNEXT greater than the source Collection, then there's a high
chance for RID conflict until the Resource replays the change
and updates the RID of the moved Item.

This change reset RID of all moves Items and only emits the RID
as part of the change notification. The Monitor then retrieves the
Item without the RID and restores the RID from the Notification,
so this is absolutely transparent to Resources.
FIXED-IN: 5.4.1

M  +7    -0    src/core/monitor_p.cpp
M  +13   -19   src/server/handler/move.cpp

https://commits.kde.org/akonadi/66b87061f523e392236d73dea668ddf6772eb545

*** Bug 352249 has been marked as a duplicate of this bug. ***

For me this does not happen for IMAP folders but for local, maildir, ones. Actually again after each deletion of an email.

Does this sound related?

Running an up-to-date ARCH installation actually containing akonadi 16.12.0-1.

Some more details can be found here: https://bbs.archlinux.org/viewtopic.php?pid=1682923#p1682923

Today the 5.4.1 arrived for my ARCH installation. The problem is not gone unfortunately - at least the one that my mail contents/folder contents do no longer show up after some deletion(s). Symptoms seem to have changed a little bit as it no longer happens immediately after each deletion. But after doing some more I still have to restart the akonadi server to get mails displayed again.

The Debugger tab of the Akonadi Console shows in the lower part some error messages, that arised after last re-start of the akonadi server until kmail being blocked:

AgentBase(akonadi_maildir_resource_0): Multiple merge candidates, aborting
AgentBase(akonadi_maildir_resource_0): Multiple merge candidates, aborting

The Konsole window having restarted the akonadi server from the last time () shows backtrace that I will attach in a moment.

Created attachment 103395 [details]
Backtrace shown in Konsole for akonadi no longer showing mails from within maildir

I also see this with KDE Applications 16.12.1 and KDE Frameworks 5.30.1 (and KDE Plasma 5.9.1, but that should be unrelated).

In this bug it says "Version Fixed In: 5.4.1" - version 5.4.1 of what exactly? I would think that I am well beyond 5.4.1 in both areas...

(In reply to Dennis Schridde from comment #65)
> I also see this with KDE Applications 16.12.1 and KDE Frameworks 5.30.1 (and
> KDE Plasma 5.9.1, but that should be unrelated).
> 
> In this bug it says "Version Fixed In: 5.4.1" - version 5.4.1 of what
> exactly? I would think that I am well beyond 5.4.1 in both areas...

Of KDE PIM. AFAIK it has its own versioning besides the KDE applications.

The workaround is also documented here: https://wiki.meurisse.org/wiki/Workarounds#Kmail:_Multiple_merge_candidates.2C_aborting

(In reply to Ovidiu-Florin BOGDAN from comment #66)
> (In reply to Dennis Schridde from comment #65)
> > I also see this with KDE Applications 16.12.1 and KDE Frameworks 5.30.1 (and
> > KDE Plasma 5.9.1, but that should be unrelated).
> > 
> > In this bug it says "Version Fixed In: 5.4.1" - version 5.4.1 of what
> > exactly? I would think that I am well beyond 5.4.1 in both areas...
> 
> Of KDE PIM. AFAIK it has its own versioning besides the KDE applications.

I'm on Gentoo and have kde-apps/libkdepim-16.12.1 installed. There is no version 5.4.1 available.

On Donnerstag, 9. Februar 2017 18:28:10 CET you wrote:
> https://bugs.kde.org/show_bug.cgi?id=338658
> 
> I'm on Gentoo and have kde-apps/libkdepim-16.12.1 installed. There is no
> version 5.4.1 available.

Don't confuse the KDE Applications Release version with the  Program
version.  It's often the same but not always.

kde applications 16.12.1 release contains 5.4.1: Kmail -> Help -> About Kmail, or

$ kmail --version
kmail2 5.4.1

$ dpkg -l kmail\* | tail -1
ii  kmail          4:16.12.1-0neon+16.04+build7 amd64        full featured graphical email client


Some (most?) PIM maintainers don't want to set the version of their Program
to the same version as the KDE Applications Release.  IMHO confusing for users.

Achim

Then I request to reopen this, please.

I saw the message "Multiple merge candidates, aborting" while using KMail 5.4.1 (KDE Applications 16.12.1) as mentioned before (comment #65) and I still see it in KMail 5.4.2 (KDE Applications 16.12.2). KMail also regularly refused to sync the IMAP account where this happens until I restart Akonadi.

Reopening.

Are there certain steps or specific setups needed to reproduce?

(In reply to Christoph Feck from comment #71)
> Are there certain steps or specific setups needed to reproduce?

I have no clue how to gather additional information about the issue. I don't even know what messages or folders cause the error, because there is no error message.

I will recap my setup and symptoms, though:

Setup:
* Server
  - Gentoo Linux
  - Dovecot 2.2.27
    - dbox mailboxes
  - Dovecot Pigeonhole 0.4.16
    - Heavy use of Sieve scripts to sort mailing lists and spam
  - Dovecot Antispam 2.0_pre20130429
    - My spam and ham folders should be monitored and acted upon by this plugin, but it appears to not do anything at all.
* Client 1
  - Gentoo Linux
  - KMail 5.4.2
  - KDE Apps 16.12.2
  - KDE Frameworks 5.31.0
  - KDE Plasma 5.9.2
  - No client side filtering. I use Sieve exclusively.
  - The error appears here.
  - I use this client on a daily basis, when I am at home.
* Client 2
  - Arch Linux
  - KMail 5.4.2
  - KDE Apps 16.12.2
  - KDE Frameworks 5.31.0
  - KDE Plasma 5.9.2
  - No client side filtering. I use Sieve exclusively.
  - The error does not appear here.
  - I use this client only very very seldomly. The machine mostly stays powered off.
* Client 3
  - Roundcube 1.2.3
  - No client side filtering. I use Sieve exclusively.
  - I use this client on a daily basis, when I am not at home.
* Client 4
  - Android 6.0.1 / Cyanogenmod 13
  - Whatever the default mail client is there...
  - I use this client on a daily basis, throughout the whole day.

The mail account itself consists of a lot of (ca. 200 [1]) nested mailboxes (up to 4 levels: /1/2/3/4). Some of these are rather large (10 contain >5k mails, the largest being at 25k [2]).

The following was observed on "Client 1":

* KMail syncs the "sent" folder (7k mails) every time, which takes a few seconds. All other folders just flash by so quickly I can barely read their name.
* After the multiple-merge-candidates error appeared, KMail sometimes continues working (i.e. further clicks on "Check Mail" start a sync), but sometimes this account will not appear on the sync details list (behind up-arrow at bottom right of screen) again, until I run "akonadictl restart".
* There is no visible error message (not counting the one displayed in the sync details list, because it is hidden behind a button, only displayed very briefly and without an indication that it is an error).
* There is no hint what mail or mailbox is causing this.
* KMail never recovers from this error. I.e. it does not merge the mails automatically or ask me for help.

[1]: doveadm -f flow fetch -u $USER mailbox-guid all | sort -u | wc -l
[2]: doveadm -f flow fetch -u $USER mailbox-guid all | sort | uniq -c | sort -n

(In reply to Dennis Schridde from comment #72)
> (In reply to Christoph Feck from comment #71)
> > Are there certain steps or specific setups needed to reproduce?

If that's of any help: While writing comment #72, mail was syncing fine. But when I returned to my computer just now, it had stopped and I had to run "akonadictl restart" again. Already the mail emitted by bugzilla for comment #72 did not arrive at my client anymore.

I am at KDE Applications 17.04.2 now and the problem appeared again:
```
akonadi_imap_resource[12572]: org.kde.pim.akonadicore: Creating/updating items 
from the akonadi database failed: "Unknown error."
akonadi_imap_resource[12572]: org.kde.pim.akonadicore: Creating/updating items 
from the akonadi database failed: "Unknown error."
akonadi_imap_resource[12572]: org.kde.pim.akonadicore: Creating/updating items 
from the akonadi database failed: "Unknown error."
akonadi_imap_resource[12572]: org.kde.pim.akonadicore: Creating/updating items 
from the akonadi database failed: "Unknown error."
akonadi_imap_resource[12572]: org.kde.pim.akonadicore: Creating/updating items 
from the akonadi database failed: "Unknown error."
akonadi_imap_resource[12572]: org.kde.pim.akonadicore: Creating/updating items 
from the akonadi database failed: "Unknown error."
akonadi_imap_resource[12572]: org.kde.pim.akonadicore: Creating/updating items 
from the akonadi database failed: "Unknown error."
akonadi_imap_resource[12572]: org.kde.pim.akonadicore: Creating/updating items 
from the akonadi database failed: "Unknown error."
akonadi_imap_resource[12572]: org.kde.pim.akonadicore: Creating/updating items 
from the akonadi database failed: "Unknown error."
akonadi_imap_resource[12572]: org.kde.pim.akonadicore: Creating/updating items 
from the akonadi database failed: "Unknown error."
akonadi_imap_resource[12572]: org.kde.pim.akonadicore: Creating/updating items 
from the akonadi database failed: "Multiple merge candidates, aborting"
akonadi_imap_resource[12572]: org.kde.pim.akonadicore: Error during ItemSync:  
"Multiple merge candidates, aborting"
```
(All messages appear in the log within the same second.)

I also see this a little bit later, but it is probably not related?
```
kmail[5475]: org.kde.pim.kmanagersieve: void KManageSieve::SessionThread::slotSocketError() "Unknown error"                                                     
kmail[5475]: org.kde.pim.kmanagersieve: "session3" No job for reporting this error message! "Could not connect to host Unknown error."                          
```

(In reply to Dennis Schridde from comment #74)

The workaround still works: https://wiki.meurisse.org/wiki/Workarounds#Kmail:_Multiple_merge_candidates.2C_aborting

Could this please be automated?

For what its worth, I still see this with Fedora 26.

 rpm -qa | grep kmail | sort
kf5-kmailtransport-17.04.1-1.fc26.x86_64
kf5-kmailtransport-akonadi-17.04.1-1.fc26.x86_64
kmail-17.04.1-3.fc26.x86_64
kmail-account-wizard-17.04.1-1.fc26.x86_64
kmail-libs-17.04.1-3.fc26.x86_64

$ rpm -qa | grep akonadi | sort
akonadi-calendar-tools-17.04.1-1.fc26.x86_64
akonadiconsole-17.04.1-1.fc26.x86_64
akonadi-import-wizard-17.04.1-1.fc26.x86_64
kf5-akonadi-calendar-17.04.1-1.fc26.x86_64
kf5-akonadi-contacts-17.04.1-1.fc26.x86_64
kf5-akonadi-mime-17.04.1-1.fc26.x86_64
kf5-akonadi-notes-17.04.1-1.fc26.x86_64
kf5-akonadi-search-17.04.1-1.fc26.x86_64
kf5-akonadi-server-17.04.1-3.fc26.x86_64
kf5-akonadi-server-mysql-17.04.1-3.fc26.x86_64
kf5-kmailtransport-akonadi-17.04.1-1.fc26.x86_64
kf5-libkdepim-akonadi-17.04.1-1.fc26.x86_64
kf5-mailimporter-akonadi-17.04.1-1.fc26.x86_64
kf5-pimcommon-akonadi-17.04.1-1.fc26.x86_64

I confirmed this issue with kmail 5.5.2 (openuse 42.3). It also happened with local folders (maildir). Akonadi restart does not work. 
Two workarounds works :
- clear akonadi cache on the folder and restart akonadi and kmail
- connect to mysql to delete items (see comment 75)

It happened multiple times per day and make kmail amost unusable...

It happens in KMail 5.5.3 (KDE Neon) on a regular basis in a local folder for a mailing list. The mails are moved to this folder using a standard mailing list filter on incoming mail from a POP3 account.

Still reproducible on Arch with KMail 5.6.1 and Akonadi 17.08.

Akonadi hangs after each "Check Mail" and must be restarted to receive any more mail. The steps described here https://www.dvratil.cz/2017/01/kmail-multiple-merge-candidates-error-and-how-to-fix-it/ don't permanently fix the problem, it recurs soon after.

Just to give this a nudge, I still see this with 17.12 on Fedora 27.

(In reply to andreas.sturmlechner from comment #53)
I am trying to execute the following query:
DELETE FROM pimitemtable
WHERE pimitemtable.id in (
  SELECT id FROM (
    SELECT id
    FROM pimitemtable
    LEFT OUTER JOIN (
      SELECT MIN(pimitemtable.id) as RowId, pimitemtable.remoteId, pimitemtable.collectionId
      FROM pimitemtable
      GROUP by pimitemtable.remoteId, pimitemtable.collectionId)
    AS KeepRows ON pimitemtable.id = KeepRows.RowId
    WHERE KeepRows.RowId IS NULL)
  AS _)

But I get this error:
Lock wait timeout exceeded; try restarting transaction QMYSQL: Unable to execute query

I am using KDE Applications 17.12.1, KDE Frameworks 5.42.0, Qt 5.9.3, MariaDB 10.2.12.

This is still broken in 5.7.2.

I have had to move away from KMail for normal use due to this bug; silently failing to recieve emails (until I manually poke the database, no less) every few hours isn't a behaviour I can cope with.

Heh - funny you should mention this - I've recently had to do the same for my work gmail based mail. Thunderbird is soooo slow by comparison - kmail is clearly better - but having mail break a dozen times a day isn't usable.

I still use kmail for my home dovecot IMAP mail - and its perfect - but akonadi really doesn't like gmail at all.

That's odd, the problematic account in my case is on a Dovecot server (2.2.7 now).

That is interesting.

I am currently using Fedora 27 - which includes dovecot 2.2.33 without issues. In fact, I'm not sure I have ever seen this issue with dovecot as the IMAP server.

My problems are purely with the gmail integration. I was assuming that this problem only affects gmail.

mmm, gmail works fine in my system (up-t-date KDE neon User Edition), so I guess it's not an entirely general issue with gmail.

do you have problems in receiving, in sending or both?

for the case it helps:

my settings for receiving emails are set automatically (I guess this is sth that changed recently, it wasn't like that before).

my sending settings are: TLS 587 LOGIN

I never had problems sending - only receiving...

I've often wondered if the 'IMAP' connection to gmail goes away unexpectedly that it causes this problem - but have had no real way to prove this.

Just leaving kmail open for a couple of hours with the auto-check for every 10-15 minutes is enough to cause the problem. It seems to get worse when using mail filters - as I have quite a few.

In fact, thinking out loud, I wonder if the mail filters have any contribution to this?

(In reply to Steven Haigh from comment #87)
> In fact, thinking out loud, I wonder if the mail filters have any
> contribution to this?

I hit the same with no local filters -- all my filter is a server-side Sieve script.

My mailserver is running Dovecot 2.2.33.2, but given the various reports about other providers, I doubt that's related.

Well, me being a sucker for punishment - with a new laptop - I set up kmail on a fresh install of Fedora 27.

Sync'ed my gmail account to it.

The very next day, hit by this problem.

From the console:
org.kde.pim.akonadicore: Creating/updating items from the akonadi database failed: "Unknown error."
org.kde.pim.akonadicore: Creating/updating items from the akonadi database failed: "Unknown error."
org.kde.pim.akonadicore: Creating/updating items from the akonadi database failed: "Unknown error."
org.kde.pim.akonadicore: Creating/updating items from the akonadi database failed: "Unknown error."
org.kde.pim.akonadicore: Creating/updating items from the akonadi database failed: "Multiple merge candidates, aborting"

So yeah - this is still an issue.

So as we're now looking at nearly 4 years on with this issue, are we any closer to looking for a final resolution?

I see new commits on the kmail git repo, but it looks like there's only one person looking after it?

FWIW, I removed all local filters from the affected account (in favour of Sieve) and so far the issue hasn't recurred using Dovecot. Given that it previously happened multiple times per day, filters are clearly one possible cause of this.


(Some people above reported problems even without filters, so perhaps there's more than one trigger with similar symptoms.  Debugging could be "fun"...)

(In reply to Francis Herne from comment #91)
> FWIW, I removed all local filters from the affected account (in favour of
> Sieve) and so far the issue hasn't recurred using Dovecot. Given that it
> previously happened multiple times per day, filters are clearly one possible
> cause of this.
> 
> 
> (Some people above reported problems even without filters, so perhaps
> there's more than one trigger with similar symptoms.  Debugging could be
> "fun"...)

I also use Dovecot + Sieve and am running into the issue occasionally.

I use kmail with Dovecot + Sieve at home - and I never seem to have an issue.

I use kmail with Gmail at work with local filters, and it dies multiple times a day. Every time it requires the documented (in this report anyway) SQL query to fix and a restart of the akonadi services via akonadictl restart.

Same distro, same kmail / framework versions.

I'm in the middle of setting up a local set of folders and syncing the gmail account with offlineimap to see if that suffers the same problem - but I think this is going to be the only workaround that is somewhat reliable...

Interestingly, I disabled the local filters on my gmail account today from within Kmail and haven't had to restart akonadi all day.

Maybe there is something within the local filters that causes things to die?

Created attachment 111525 [details]
attachment-21853-0.html

The bug is this:
emails contain an ID field in the header, usually a combination of a
timestamp + source ip or email address
kmail assumes that this ID is unique, but does a query that can return
multiple results.
It pukes every time duplicate emails are returned and it never recovers
from this status.

I proposed a fairly simple patch to fix this, just select the first result
from the query, and be done with it.
Sadly, the maintainer was unwilling to accept it, and the bug remains open

Usually these duplicates are multiple references to the same email, via
filters, or similar things.
(I have accidentally generated different emails with the same id, while
messing with git-send-email, but that is
an extremely rare edge case and I was doing wrong things out of ignorance
at the time)


I can no longer find which bug report my was attached to. It has been too
long, Sorry.

On Sun, Mar 18, 2018 at 11:56 PM, Steven Haigh <bugzilla_noreply@kde.org>
wrote:

> https://bugs.kde.org/show_bug.cgi?id=338658
>
> --- Comment #94 from Steven Haigh <netwiz@crc.id.au> ---
> Interestingly, I disabled the local filters on my gmail account today from
> within Kmail and haven't had to restart akonadi all day.
>
> Maybe there is something within the local filters that causes things to
> die?
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.
>

Thanks for the additional info - would it be too much to ask to find the previous patch?

I guess the idea was along the lines of a LIMIT 1 in scenarios where more than one result would kill the world.

Ideally, this could be a runtime fix - and the fsck ability of akondactl could remove duplicate entries.

I still use this code in the SQL tab of akonadiconsole:
DELETE FROM pimitemtable WHERE pimitemtable.id in (
    SELECT id FROM (
        SELECT id FROM pimitemtable
        LEFT OUTER JOIN (
            SELECT MIN(pimitemtable.id) as RowId, pimitemtable.remoteId, pimitemtable.collectionId FROM pimitemtable GROUP by pimitemtable.remoteId, pimitemtable.collectionId
        )
        as KeepRows ON pimitemtable.id = KeepRows.RowId
        WHERE KeepRows.RowId IS NULL
    ) AS foo
)

Source:
https://wiki.meurisse.org/wiki/Workarounds#Kmail:_Multiple_merge_candidates.2C_aborting

This seems to resurrect things until it occurs again.

Still annoying and really needs to be fixed.

I looked really hard for it and didn't find it yesterday... but somehow when I looked again this morning it is the second result.
My patch was attached to 

https://bugs.kde.org/show_bug.cgi?id=376808

Thanks for the link.

@Daniel Vrátil - Can you please advise on the thoughts to resolve this?

Seems to be a long standing / high impact issue with no progress.

*** Bug 376808 has been marked as a duplicate of this bug. ***

*** Bug 382253 has been marked as a duplicate of this bug. ***

*** Bug 393795 has been marked as a duplicate of this bug. ***

I also see this on a regular basis, though it doesn't always completely stall imap account, or at least didn't with my last version, but now does so again.

Is there a way to change the number of akonadi_imap restarts allowed? 

org.kde.pim.akonadicontrol: Application '/usr/bin/akonadi_imap_resource' crashed! 1 restarts left.

I'd just like to run a cronjob to kill akonadi_imap silently every hour so I wasn't bugged with this problem.

Hello, 

Is it the same PB I opened  : Bug 395417 - I've to restart akonadi several times during day for get Google IMAP access refreshing

Probably the same issue. Its been around for ever and I'm not sure anyone cares...

FWIW I've tried the suggestions that this is related to kmail filters by deleting all my filters and I can report that this has _not_ fixed the problem because an hour later kmail has stopped (yet again) collecting mail.

This is a ridiculous state of affairs - a major flavour of linux's flagship email system cannot receive email, numerous bug reports and apparently SFA going on.

What I do know is older versions of kmail do not have this problem even now. So I suspect that the recent duplicates added here are not duplicates of the original problem.

*** Bug 382253 has been marked as a duplicate of this bug. ***

*** Bug 397756 has been marked as a duplicate of this bug. ***

*** Bug 397755 has been marked as a duplicate of this bug. ***

I doubt my problem was ever this bug but, FWIW it appears to be working again in 5.7.3

I too am still experiencing this problem with 17.12.3 in OpenSuSE 15.0, both with my home IMAP server (Cyrus) and work (Office365). I configured it to use Postgresql.

And this happened again today, and yesterday, all in all about five or six times this week. Except that running Stephan's sql statement still doesn't make kmail download mail on this laptop. Maybe we should just spam this bug report every singe time this happens? That might might show how _bad_ the situation.

Created attachment 115298 [details]
experimental patch

I have been using this patch for months to keep akonadi working on my machine.

I'm not building akonadi myself, so I cannot test the patch, but if you've been using it for months... It probably should be good, shouldn't it?

I think it is a safe and it works, but it doesn't solve the underlying issue, it just makes kmail keep working when the data is wrong.

I think it is a safe and it works, but it doesn't solve the underlying issue, it just makes kmail keep working when the data is wrong.

Well, that's important too. I mean... Releasing a mail client that without any message to the user just stops working is a bit problematic. Better keep it working, while the underlying bug gets fixed.

i too am affected by this. i have to restart akonadi at least once a day. right now one of the configured IMAP resources hangs with a subfolder being fetched at 116% (guess it would also confuse me if i tried to fetch more than there is).

I pushed my patch for review. One side effect I have noticed though, is that affected folders ends up being redownloaded frequently as the number of messages doesn't match upstream, but the duplicates are not deleted during the sync, so it happens again and again. That should probably be fixed, at least a full sync from remote should get rid of the duplicate.

This still happens in KDE 5.54 every one og two months. The only real solution is to recreate the mail account. I use dovecot as imap server.

While this is still a problem, could'nt you a a functionality that just recreates the account. Just so we are not forced to enter the credentials and setup folders and such?

I'm fed up with wiping my Akonadi data every other month so I'm trying to once again to understand the cause or find a workaround.

Anyway, I was following the SQL hints on debugging the state of my Akonadi data and found three instances of duplicated (well, rather "multiplicated") pimitemtable.remoteIds, on the order of hundreds of different pimitemtable.ids. I then tried to find the corresponding data in parttable via INNER JOIN parttable ON pimitemtable.id = parttable.pimItemId. Interestingly enough there's a single pimitemtable.id per pimitemtable.remoteId left (with three different parttable.id per pimitemtable.id, which seems to be correct for normal entries). So it seems there are stale entries in pimitemtable. The query

SELECT pimitemtable.*, collectiontable.name FROM pimitemtable
INNER JOIN collectiontable ON pimitemtable.collectionId = collectiontable.id
LEFT JOIN parttable ON pimitemtable.id = parttable.pimItemId
WHERE parttable.id IS NULL

lists the same remoteIds that the query looking for dups found, minus the ones that have a match in parttable. Useful information: there are no additional stale entries in pimitemtable than the dups.

Next step, I tried to remove the stale entries in pimitemtable with the following query:

DELETE pimitemtable FROM pimitemtable
LEFT JOIN parttable ON pimitemtable.id = parttable.pimItemId
WHERE parttable.id IS NULL

However, the query hangs akonadiconsole for ~1 minute and then returns "Lock wait timeout exceeded; try restarting transaction QMYSQL: Unable to execute query". An `akonadictl restart` in this case did the trick and the query then got through. All dups gone. In any case the hangs on reading mails in KMail that I experienced since yesterday are gone. Let's see whether it helps.

Maybe the DELETE query is a useful addition to `akonadictl fsck` until the root cause can be fixed?

With my patch in place the duplicates can be removed by simply calling "remove duplicates" from KMail.

(In reply to Allan Sandfeld from comment #122)
> With my patch in place the duplicates can be removed by simply calling
> "remove duplicates" from KMail.

"Folder -> Remove Duplicates"? If that removes stales in the pimitemtable it's somewhat misleadingly named. I was expecting it to search for copies of the same mail (i.e. different local & remote ID but equal payload data).

(In reply to Matthias Kretz from comment #123)
> (In reply to Allan Sandfeld from comment #122)
> > With my patch in place the duplicates can be removed by simply calling
> > "remove duplicates" from KMail.
> 
> "Folder -> Remove Duplicates"? If that removes stales in the pimitemtable
> it's somewhat misleadingly named. I was expecting it to search for copies of
> the same mail (i.e. different local & remote ID but equal payload data).

It is not what it is supposed to do, but those exact copies of a single remote entry also match as if they are just normal copies of the same email.

Btw. I believe the underlying cause is the same that causes emails you are currently reading to be marked unread again while you are reading it. A sync is often started in parallel with other actions, so for instance you click on a folder it starts syncing, and you are reading an email and it is marked read. You mark it read, but the sync then marks it unread (race condition). 

The same can happen when moving emails, it might be moved, only to be recreated by the parallel sync, and then moved again, causing two exact copies to exist in the target folder.

The transactional atomicy of Akonadi is somewhat questionable with several jobs that consists of multiple database transactions, or is combined with syncing remote servers.

I tried looking at the move job, but it is pretty messy.

That sounds very likely -- I see the read-unread flip all the time as well.

The fact that I can have an inconsistent state stored in my Akonadi DB is telling. Apparently, while clients interact with Akonadi, the DB goes through inconsistent states. Those appear to be open to races, and unfortunate interrupts (crash, system hang, power loss).

What I'd do (and I'm guessing from a far away distance in the hopes it helps inspire a real fix, hoping not to step on any toes):

1. Update the DB schema to enforce consistent state. In particular all foreign keys need to be defined so that it's impossible to DELETE FROM parttable while something in pimitemtable still holds a key to it.

2. Presumably this will break clients which rely on the DB to allow inconsistent intermediate states. DB updates therefore need to be fixed to atomically go from one consistent state to the next. E.g. use DELETE together with INNER JOIN.

3. Races like "unread -> read -> unread" need to be guarded against via compare-exchange atomic operations using some modification counter. E.g.
mailcheck create id=X, state=unread
kmail read id=X, state=unread
kmail write state=read WHERE id=X
mailcheck update id=X, state=unread (why would this happen anyway, can the IMAP server indicate some update of metadata?)

If we add a version the UPDATE could be predicated on the version column still storing the same value as when it was SELECTED before. E.g. the mail client does
`UPDATE foo SET state=read WHERE id=X AND version=1` instead of `UPDATE foo SET state=read WHERE id=X`. I actually expect Akonadi already has such a facility and Allans guess is incorrect.

I have another guess from looking at my logs. I have lots of:

org.kde.pim.akonadiserver:   DB error:  "Lock wait timeout exceeded; try restarting transaction"
org.kde.pim.akonadiserver:   Error text: "Lock wait timeout exceeded; try restarting transaction QMYSQL3: Unable to execute statement"

I.e. KMail updates the UI to read state, tries to reflect the state change with Akonadi, but the DB is locked up. The UPDATE fails, and the KMail UI reverts to the state stored in Akonadi.

These locks might also be the reason why inconsistent entries in tables remain. A first DELETE goes through, the second (to make it consistent again) times out.

I have no clue where the locks come from though. One data point: After my DELETE FROM statement above I've not seen a single DB error message about lock timeouts again. Before I had lots.

Its back - this went away for a few months but its back and its so annoying - akonadi restarts 5 times today - akonadi just hangs.

anyone got a simple way to restart the imap part I can us in a script? it would be so helpful.

I don't think that *anyone* knows what the problem is. This "mail in database"-system should never have been done in the first place. I still use kmail/kontact but tt has been functioning suboptimal all the years.

I switched to Geary, it's beautiful and modern and works perfectly with gmail. It's GTK but it works perfectly in KDE :D

Could someone just add a watchdog timer to it so it just restarts if it gets stuck? I've tried scripting an akonadictl function to do this but akonadictl insists on spamming up the desktop with irrelevant error messages.

Git commit 8f230d7d7f8a4e2b97273585374a68902b5ef6cf by Daniel Vrátil.
Committed on 31/05/2019 at 11:21.
Pushed by dvratil into branch 'master'.

Automatic recovery from Multiple Merge Candidates error

Summary:
Introduce a recovery codepath when Multiple Merge Candidates error
occurs during Item merging. Since clients generally do not use
merging, this really only happens during ItemSync. In such case we
quitely delete all the conflicting items from the database and reschedule
the collection sync. The next sync should then succeed and bring the
collection into a consistent state.

Note that this does not fix the Multiple Merge Candidates bug - it can
still happen (and we still don't know how), but Akonadi should now be
able to recover from it automatically without user intervention, thus
making this issue less of a PITA.

Test Plan: Successfuly auto-recovered a broken collection on my setup.

Reviewers: #kde_pim, dfaure

Reviewed By: dfaure

Subscribers: vkrause, dfaure, ngraham, asturmlechner, kde-pim

Tags: #kde_pim

Differential Revision: https://phabricator.kde.org/D21455

M  +3    -3    autotests/server/fakedatastore.cpp
M  +1    -1    autotests/server/fakedatastore.h
M  +65   -4    src/server/handler/itemcreatehandler.cpp
M  +4    -0    src/server/handler/itemcreatehandler.h
M  +18   -16   src/server/storage/datastore.cpp
M  +3    -1    src/server/storage/datastore.h

https://commits.kde.org/akonadi/8f230d7d7f8a4e2b97273585374a68902b5ef6cf

Great work Daniel. I switched from kmail to thunderbird some months ago and I hate it. I look forward to this automatic repair getting into my distribution :)

Git commit 8332cf8a5aa39df6fb665cdbff1a48286d5698f5 by Sandro Knauß, on behalf of Daniel Vrátil.
Committed on 30/08/2019 at 08:48.
Pushed by knauss into branch 'Applications/18.08'.

Automatic recovery from Multiple Merge Candidates error

Summary:
Introduce a recovery codepath when Multiple Merge Candidates error
occurs during Item merging. Since clients generally do not use
merging, this really only happens during ItemSync. In such case we
quitely delete all the conflicting items from the database and reschedule
the collection sync. The next sync should then succeed and bring the
collection into a consistent state.

Note that this does not fix the Multiple Merge Candidates bug - it can
still happen (and we still don't know how), but Akonadi should now be
able to recover from it automatically without user intervention, thus
making this issue less of a PITA.

Test Plan: Successfuly auto-recovered a broken collection on my setup.

Reviewers: #kde_pim, dfaure

Reviewed By: dfaure

Subscribers: vkrause, dfaure, ngraham, asturmlechner, kde-pim

Tags: #kde_pim

Differential Revision: https://phabricator.kde.org/D21455

(cherry picked from commit 8f230d7d7f8a4e2b97273585374a68902b5ef6cf)

M  +3    -3    autotests/server/fakedatastore.cpp
M  +1    -1    autotests/server/fakedatastore.h
M  +67   -5    src/server/handler/akappend.cpp
M  +4    -0    src/server/handler/akappend.h
M  +18   -16   src/server/storage/datastore.cpp
M  +3    -1    src/server/storage/datastore.h

https://commits.kde.org/akonadi/8332cf8a5aa39df6fb665cdbff1a48286d5698f5

I have had no problems for the last 3 months - so the recovery method seems to work for me!

For anyone stepping by (probably on KUbuntu 18.04)

https://docs.kde.org/trunk5/en/pim/kmail2/clean-start-after-a-failed-migration.html
- Kmail->Tools->Impoexrt/Export => Export backup
- close kmail
- akonadictl stop
- rm -rf ~/.local/share/akonadi ~/.config/akonadi
- akonadictl start
- imported data*

problems:
- * you can't import filters & account etc at once
  you have to first add all email accounts back, then import your data partially
- mailfilters file in backup is empty, dialogs question for unknown identities & folders as import is done before syncing imap accounts -> non-existing folders
- if you end up with tons of empty Identities, that take 100% CPU to remove and re-appear on kmail restart, edit ~/.config/emailidentities by hand
  my regex for this is \[Identity #\d+\]\nDefault Domain=ah\-laptop\nDisable Fcc=false\nIdentity=Unnamed\nImage Location=\nInline Signature=\nSignature Enabled=false\nuoid=\d+\n in Kate

It's still here - just had this on v 5.7.3

David, commit from comment 132 was released with KDEPIM version 5.12.0. The fix is not in older versions, such as version 5.7.3.

Closing according to comment 135; no new reports appeared for recent versions.