Kolab resource gets stuck on change replay tasks
Open, HighPublic

Description

Is only recoverable by restarting akonadi. Regularly reproducable on a user system.

It regularly gets stuck on the "Archive" folder of the user.

Details

Ticket Type
Task

Related Objects

mollekopf created this task.Oct 8 2015, 5:49 PM
mollekopf updated the task description. (Show Details)
mollekopf raised the priority of this task from to 60.
mollekopf added a project: KDE PIM.
mollekopf changed Ticket Type from Task to Task.
mollekopf added a subscriber: mollekopf.

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).

mollekopf updated the task description. (Show Details)Feb 5 2016, 9:22 AM

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:

  • LIST
  • A couple of MERGE with data and GID
  • A couple of MERGE without data (flags) <= in here we have the rollback
  • A full fetch of all items

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.

mollekopf raised the priority of this task from 60 to High.Mar 14 2016, 3:40 PM

It was suggested that the problem was created by mass moving mail to the folder.

mollekopf added a project: Restricted Project.Apr 5 2016, 2:54 PM
mollekopf moved this task from Restricted Project Column to Restricted Project Column on the Restricted Project board.Apr 5 2016, 2:55 PM