[Kde-pim] mixedmaildir resource LRCONFLICT

[David Faure]

On Thursday 19 July 2012 19:54:48 Volker Krause wrote:
> On Tuesday 17 July 2012 10:06:40 David Faure wrote:
> > Clicking on an old mail folder that uses the mixedmaildir resource, I see:
> > [...]
> > akonadi_mixedmaildir_resource_2(4471)/akonadiresource (maildir)
> > RetrieveItemsJob::Private::storeListResult: Store fetch got 1718 items of
> > which 0 are new and 1718 are changed and 0 need to be removed
> > akonadi_mixedmaildir_resource_2(4471)/akonadiresource (maildir): "NO
> > [LRCONFLICT] Resource tries to modify item with dirty payload, aborting
> > STORE.
> > 
> > and then a popup says "the resource is broken".
> > 
> > How do I debug this further?
> 
> I don't really know the internals of the mixedmaildir resource, Kevin is
> your man there. But I can comment on what the LRCONFLICT means.
> 
> "LR" stands for local/remote, ie. there are local changes that hasn't been
> played back to the backend yet at the time the resource tries to update the
> local state to what it sees in its backend.

As a novice akonadi hacker, I'm confused by some of the terms here.
Local is local to whom? The client app? The resource? The akonadi server?
The backend is the file or folder on disk here, right? (mixedmaildir-resource)

To start with an easy patch, would this be a correct way to find out more about the faulty item?

--- a/server/src/handler/store.cpp
+++ b/server/src/handler/store.cpp
@@ -136,9 +136,12 @@ bool Store::parseStream()
   for ( int i = 0; i < pimItems.size(); ++i ) {
     if ( mCheckRevision ) {
       // check for conflicts if a resources tries to overwrite an item with dirty payload
-      if ( connection()->isOwnerResource( pimItems.at( i ) ) ) {
-        if ( pimItems.at( i ).dirty() )
-          throw HandlerException( "[LRCONFLICT] Resource tries to modify item with dirty payload, aborting STORE." );
+      const PimItem& pimItem = pimItems.at( i );
+      if ( connection()->isOwnerResource( pimItem ) ) {
+        if ( pimItem.dirty() ) {
+          const QString error = QString::fromLatin1( "[LRCONFLICT] Resource tries to modify item %1 (%2) (in collection %3) with dirty payload, aborting STORE." );
+          throw HandlerException( error.arg( pimItem.id() ).arg( pimItem.remoteId() ).arg( pimItem.collectionId() ) );
+        }
       }
 
       // check and update revisions

I tried to also print out the resource name, but I think this is more difficult, i.e. it would need
to be in the JOIN of the query, right?

I ran the above, and got

"NO [LRCONFLICT] Resource tries to modify item 351480 (1229420914.8026.iOVCD:2,S) (in collection 794) with dirty payload, aborting STORE.
Collection 794 is indeed the one I just clicked on. That mail exists on disk, with that name.
The only modification that could possibly have happened is "mark as read".

> As many other things, this should never happen and is most likely damage of
> a problem that happened earlier. ResourceBase ensures that local changes
> are always replayed before loading new stuff from the backend.
> 
> The way this is implemented is the dirty flag that every item has. It's set
> on any modification from anyone but the owning resource, ie. any local
> change. The resource resets it after applying the change to its backend
> (using changeProcessed() usually).

Maybe this flag could be turned into a string, for easier debugging, representing
who/what made the change and why/where?
Hunting a value of true after the fact is quite "mission impossible"...
But of course if this is in mysql it might be too much trouble.

Or is there another way to find out about the change?

agent_config_akonadi_mixedmaildir_resource_2_changes.dat is empty BTW.

> Most likely scenarios for something like this include:
> - code path in mixedmaildir not calling changeProcessed() (but rather e.g.
> taskDone()), ie. replaying (or intentionally ignoring a change) and then
> failing to reset the dirty flag

Could crashes also lead to this? E.g. if the resource crashes after doing whatever
has to be done, but before resetting the dirty flag?

> - changes having gotten lost altogether (deleted/corrupt replay log (.dat
> file) for example)
> 
> Manual recovery would involve either triggering another change on that item
> or forcefully resetting the dirty flag. Automatic recovery would be
> preferably of course, but once you have a real conflict that's tricky. For
> LLCONFLICTS we have the infamous conflict resolution dialog.
> 
> I hope this helps a bit.

Yep, thanks for that information. I'll try to find out more, but this sounds complex,
when the actual problem is most likely in the past, and gone by now (e.g. deleted
replay log, although I'm pretty sure I didn't do that...)
But then again, a forced computer shutdown could fail to write out a file (QSaveFile won't be
in before Qt-5.1 ;)...

OK now I did another change on that item, marking it as unread again. This then gave me
the same error on the next mail... I marked all of them as unread, then all as read, and the
problem seems fixed for this particular folder...
Clicked on another (bigger) folder... as usual it has to sync it from disk, which takes a very
long time (isn't cached??) and then it says;
"NO [LRCONFLICT] Resource tries to modify item 321273 (1300895468.6368.5Ejro:2,S) (in collection 800)"
Sigh.

The ",S" means seen, right? So the status on disk is already correct...

Ah, could this be another instance of the case where the akonadi DB thinks "unread"
and the file on disk says "read" (due to an old bug), and therefore the operation "mark as read"
has nothing to do? Could it be that when this happens, it forgets to reset the dirty flag?

-- 
David Faure, faure at kde.org, http://www.davidfaure.fr
Sponsored by Nokia to work on KDE, incl. KDE Frameworks 5

_______________________________________________
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/