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

[Daniel Vratil]

On Tuesday 23 of September 2014 10:08:10 Christian Mollekopf wrote:
> 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.

I think I can reproduce this case rather easily:

I open a folder, mark some emails as read and delete some emails. Some time 
during that the Sync is started and once it finishes, the deleted emails 
appear again - this is because the the Sync is enqueued and start first (and 
the Delete/Move task is queued after Sync has started, so even with the 
ChangeReplay queue having higher priority, the task is executed after). Due to 
the async nature of Akonadi, the Item is actually removed/moved to another 
collection in Akonadi *before* the IMAP resource actually starts the 
retrieveItemsTask - which leads to the situation that you described above. 
Next time I open the folder again, the folder is fully synced.

I can reproduce it especially on larger folders, where things take more time, 
so it's easier to hit the right timing.


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

-- 
Daniel Vrátil | dvratil at redhat.com | dvratil on #kde-devel, #kontact, #akonadi
KDE Desktop Team
Associate Software Engineer, Red Hat

GPG Key: 0xC59D614F6F4AE348
Fingerprint: 4EC1 86E3 C54E 0B39 5FDD B5FB C59D 614F 6F4A E348
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20140924/2ac815c7/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/