[Kde-pim] "Detected inconsistency in local cache"

[Christian Mollekopf]

On Monday 22 September 2014 22.37:52 David Faure wrote:
> akonadi_imap_resource_0(19688)/kdepimlibs (kimap)
> RetrieveItemsTask::startRetrievalTasks: Starting retrieval for  "INBOX"
> akonadi_imap_resource_0(19688)/kdepimlibs (kimap)
> RetrieveItemsTask::onFinalSelectDone: Starting message retrieval.
> Elapsed(ms):  70 akonadi_imap_resource_0(19688)/kdepimlibs (kimap)
> RetrieveItemsTask::onFinalSelectDone: MessageCount:  215 Local message
> count:  190 akonadi_imap_resource_0(19688)/kdepimlibs (kimap)
> RetrieveItemsTask::onFinalSelectDone: UidNext:  6346 Local UidNext:  6322
> akonadi_imap_resource_0(19688)/kdepimlibs (kimap)
> RetrieveItemsTask::onFinalSelectDone: HighestModSeq:  0 Local
> HighestModSeq:  0 akonadi_imap_resource_0(19688)
> RetrieveItemsTask::onFinalSelectDone: Detected inconsistency in local
> cache, we're missing some messages. Server:  215  Local:  190
> akonadi_imap_resource_0(19688) RetrieveItemsTask::onFinalSelectDone:
> Refetching complete mailbox.
> 
> Can you explain what this means? The fact that I only had 190 emails locally
> and there were 215 on the server isn't an inconsistency, it's simply the
> result of not being online for one day. Surely that's not reason enough to
> refetch the mailbox from scratch?

The algorithm detects:
maxAvailableMessages=6346-6322=24
localCount=190
remoteCount=215

* case A: (localCount+maxAvailableMessages == remoteCount) => we can fetch new 
messages: We know only new messages arrived, so we fetch only the new ones and 
sync the flags for the rest.

* case B: (localCount+maxAvailableMessages < remoteCount) => inconsistency 
detected: because locally deleted items are always first replayed to the 
server, this should never happen, but is what you're running into. This *does* 
happen if we failed to replay a removed item to the server.

* case C: (localCount+maxAvailableMessages > remoteCount) => in this case
messages were deleted on the server, and potentially some removed as well.
We fetch the new messages in the interval localUidNext:remoteUidNext and fetch
flags for the rest to detect removed messages.

You are running into case B. Unfortunately I don't know any better way of 
recovering from failing to replay a message removal, and I think that the only 
thing we can fix. It is absolutely necessary that we catch case B, otherwise 
we end up fetching flags-only for the message, resulting in an item without 
payload and only flags in akonadi reappearing.

If you have any ideas on how to improve the algorithm, please let me know.

Cheers,
Christian


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