Is only recoverable by restarting akonadi. Regularly reproducable on a user system.
It regularly gets stuck on the "Archive" folder of the user.
Is only recoverable by restarting akonadi. Regularly reproducable on a user system.
It regularly gets stuck on the "Archive" folder of the user.
Recently seen in SyncCollectionAttribute, and the same system showed an error message "unknown attribute collectioncolor".
It's not entirely sure that the installation is clean though (proper packages etc).
The Archive folder has a subfolder and in there we see this:
... 17014 MERGE (REMOTEID SILENT) 770 0 (\MimeType[message/rfc822] "\\RemoteId[571]" \SEEN) () 17014 [UIDNEXT 854862 DATETIME "25-Jan-2016 17:57:51 +0000"] 17014 OK Merge completed 17015 MERGE (REMOTEID SILENT) 770 0 (\MimeType[message/rfc822] "\\RemoteId[572]" \SEEN) () 17015 NO Multiple merge candidates, aborting 17016 ROLLBACK 17016 OK Rollback completed 17017 BEGIN 17017 OK Begin completed 17018 FETCH 1:* COLLECTIONID 770 CACHEONLY EXTERNALPAYLOAD (UID COLLECTIONID FLAGS SIZE REMOTEID REMOTEREVISION) * 867710 FETCH (UID 867710 REV 0 REMOTEID "983" MIMETYPE "message/rfc822" COLLECTIONID 770 SIZE 8978 FLAGS (\SEEN \ANSWERED)) * 867709 FETCH (UID 867709 REV 0 REMOTEID "982" MIMETYPE "message/rfc822" COLLECTIONID 770 SIZE 60268 FLAGS (\SEEN)) * 867708 FETCH (UID 867708 REV 0 REMOTEID "981" MIMETYPE "message/rfc822" COLLECTIONID 770 SIZE 18216 FLAGS (\SEEN \ANSWERED $SIGNED)) ...
The fetch is completed (and also lists the item with remoteId 572), but then keeps silent from there on.
In total we see on the folder:
Inside the fetch we see:
* 859243 FETCH (UID 859243 REV 2 REMOTEID "572" MIMETYPE "message/rfc822" COLLECTIONID 770 SIZE 35614 FLAGS (\SEEN)) ... * 854863 FETCH (UID 854863 REV 2 REMOTEID "572" MIMETYPE "message/rfc822" COLLECTIONID 770 SIZE 15378 FLAGS (\SEEN))
Which means we have a duplicate (collectionId, mimeType, remoteId) tuple, which is illegal.
The question now becomes how that tuple was created.
The user reported that query "select * from pimitemtable where collectionId=770 and remoteId=572;" only returns one result (with id 859243), which contradicts what we see above.
The findRIDDuplicates job in the storagejanitor (akonadictl fsck) finds all duplicates, but only removes them if they don't match the mimetype of the parent collection.
Also removing other duplicates requires taking a random guess which one to nuke and we have to ensure that we don't end up replaying that change to the server.