[Kde-pim] Collections without remoteId abort imap sync

[Volker Krause]

On Sunday 19 February 2012 11:08:17 David Faure wrote:
> My IMAP sync has been broken for a long time, due to errors like this one:
> 
> 
> Error during executing query "INSERT INTO CollectionTable (remoteId,
> remoteRevision, name, parentId, resourceId, cachePolicyInherit) VALUES (:0,
> 
> :1, :2, :3, :4, :5)" :  "Duplicate entry '960-trainings-old' for key
> 
> 'CollectionTable_parentAndNameIndex' QMYSQL3: Unable to execute statement"
> 
> Volker told me to look for a collection without a remoteId, in the
> CollectionTable, and he was right, that's exactly the issue.
> 
> id 2551, remoteId empty, remoteRevision empty, name trainings-old, parentId
> 960 (which is correct), resourceId 22.
> 
> Shouldn't akonadiserver detect that and use "UPDATE" when a collection with
> this name already exists?

An empty remote id as such is perfectly valid, in the scenario outlined by 
Kevin. The identification used to decide whether to use INSERT or UPDATE is 
the Akonadi id (not the name or RID). The uniqueness check on the name is just 
an extra safety check as most backends can't handle two objects with the same 
name.

The code that breaks here is a few levels up I think, in 
Akonadi::CollectionSync in kdepimlibs. It creates a new collection instead of 
updating the RID of an existing one, see below.

> Of course I could just clean up my SQL table from such ghost collections,
> but I suppose a proper recovery code path would be more useful for other
> users in the same situation who don't have the opportunity of spending a
> weekend in Osnabrueck to get such answers about their problems :-)
> 
> Any idea how this could happen in the first place, too?

What likely happened here is you created a new folder locally (added to 
Akonadi with empty RID), the IMAP resource created it on the server and failed 
to update the RID locally to the correct IMAP path (I don't know yet why that 
would happen though). Another, less likely, scenario is a conflict of two 
clients creating the same folder simultaneously.

The above error is then triggered on the next collection tree sync. The 
collection on the server and the local one cannot be matched using their RID, 
as a result of which CollectionSync tries to create the missing one from the 
server locally (causing the name clash), at which point it aborts. 
CollectionSync would also remove local collections missing on the server, but 
there's an extra safety check to not do that for RID-less objects (as they 
haven't been written to the server yet, by the definition of the RID). So, 
that will not make it recover here.

One solution I can see is making the matching in CollectionSync slightly more 
clever for the "leftovers" (stuff that couldn't be matched by RID) and just 
update the RID accordingly when finding matching names among those.

regards,
Volker
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20120220/f9135a8d/attachment.sig>
-------------- next part --------------
_______________________________________________
KDE PIM mailing list kde-pim at kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/