[Kde-pim] Review Request: avoid the use of an undefined collection

[Kevin Krammer]

On Wednesday, 2011-10-05, Guy Maurel wrote:

> I see the problem at file
> kdepimlibs/akonadi/specialcollectionshelperjobs.cpp at line 419:
> q->emitResult();
> This trigged over 15 calls the method
>   OutboxQueue::Private::localFoldersRequestResult
> 
> which says:
> 323?>  if ( job->error() ) {
> 324?     // We tried to create the outbox, but that failed. This could be
> because some 332?       kWarning() << "Failed to get outbox folder.
> Retrying in: " << timeout;
> 
> and after 8 times (OUTBOX_DISCOVERY_RETRIES)
> 335?       kWarning() << "Failed to get outbox folder. Giving up."; ;
> 336?       emit q->error( i18n( "Could not access the outbox folder (%1).",
> job->errorString() ) );
> 
> All this has *nothing* to do with the first call.
> 
> A look at the debugger-Window from Akonadi Console gives us:
> 0x8632950 * OK Akonadi Almost IMAP Server [PROTOCOL 28]
> 0x8632950 0 LOGIN "akonadi_maildispatcher_agent"
> akonadi_maildispatcher_agent (0x8632950) 0 OK User logged in
> akonadi_maildispatcher_agent (0x8632950) 1 LSUB 0 INF (RESOURCE
> akonadi_maildir_resource_0) (STATISTICS true) akonadi_maildispatcher_agent
> (0x8632950) 1 OK List completed
> akonadi_maildispatcher_agent (0x8632950) 2 LSUB 0 INF (RESOURCE
> akonadi_maildir_resource_0) (STATISTICS true) akonadi_maildispatcher_agent
> (0x8632950) 2 OK List completed
> akonadi_maildispatcher_agent (0x8632950) 3 LSUB 0 INF (RESOURCE
> akonadi_maildir_resource_0) (STATISTICS true) akonadi_maildispatcher_agent
> (0x8632950) 3 OK List completed
> akonadi_maildispatcher_agent (0x8632950) 4 LSUB 0 INF (RESOURCE
> akonadi_maildir_resource_0) (STATISTICS true) akonadi_maildispatcher_agent
> (0x8632950) 4 OK List completed
> akonadi_maildispatcher_agent (0x8632950) 5 LSUB 0 INF (RESOURCE
> akonadi_maildir_resource_0) (STATISTICS true) akonadi_maildispatcher_agent
> (0x8632950) 5 OK List completed
> akonadi_maildispatcher_agent (0x8632950) 6 LSUB 0 INF (RESOURCE
> akonadi_maildir_resource_0) (STATISTICS true) akonadi_maildispatcher_agent
> (0x8632950) 6 OK List completed
> akonadi_maildispatcher_agent (0x8632950) 7 LSUB 0 INF (RESOURCE
> akonadi_maildir_resource_0) (STATISTICS true) akonadi_maildispatcher_agent
> (0x8632950) 7 OK List completed
> akonadi_maildispatcher_agent (0x8632950) 8 LSUB 0 INF (RESOURCE
> akonadi_maildir_resource_0) (STATISTICS true) akonadi_maildispatcher_agent
> (0x8632950) 8 OK List completed
> 
> and
> AgentBase(akonadi_maildispatcher_agent): Could not access the outbox folder
> (Unknown error. (Failed to fetch the resource collection.)).
> 
> My proposal is a little bit "complicated" but it avoid these erroness
> messages.

With the context you have provided (outboxqueue requesting outbox folder), I 
did a bit of digging.

The code creating and running the DefaultResourceJob expects it either to 
deliver all special collections it could find but at least the resource's top 
level collection so it can create all missing ones.

Returning from DefaultResourceJobPrivate::collectionFetchResult() without an 
error *and* without a valid top level collection violates that expectation.
(A debug build should actually assert in 
SpecialCollectionsRequestJobPrivate::createRequestedFolders(), it checks for 
scanJob->rootResourceCollection().isValid())

The error in DefaultResourceJob is therefore correct, the problem is tha 
OutboxQueue is attempting retries without anyone trying to recover from the 
problematic situation, thus repeatedly failing and finally giving up.

One thing we could to as an attempt of recovery is to determine whether not 
getting any collections is an error or just bad timing.

Since our CollectionFetchJob returned without error we can be sufficiently sure 
that the resource exists. Since we didn't get any collectionswe could be 
facing a situation where the resource has just not synchronized its collection 
tree yet.

We can therefore ask for that to happen before jumping to the conclusion that 
there is something wrong with the resource.

For 4.8 branch (master) we can use ResourceSynchronizationJob's new 
setCollectionTreeOnly() method to request that and retry collection fetch when 
it succeeds.

For 4.7, where we don't have this available yet, we'll probably have to resort 
to something less nice.

One option would be to still use ResourceSynchronization job, but this could 
potentially take quite long to run because it will do a full sync (including 
all items, i.e. reading at least all mail headers).

Another option would be to trigger collection tree sync by calling 
synchronizeCollectionTree() on the resource's AgentInstance object and then 
still fail with the error, i.e. hoping that the next retry will face a better 
situation.

Which branch are you currently developing with?

Cheers,
Kevin
-- 
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring
-------------- 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/20111009/e542a8db/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/