[Kde-pim] Making offline/online handling sane

[Volker Krause]

On Sunday 09 December 2012 16:23:12 Kevin Krammer wrote:
> On Saturday, 2012-12-08, Volker Krause wrote:
> > On Saturday 08 December 2012 12:26:38 Georg C. F. Greve wrote:
> > > Those items then have a local, but no remote ID, which means they have
> > > not actually been pushed to the server, and Akonadi has no recovery from
> > > this fairly common [*] scenario, it seems.
> > 
> > Correct, if the change replay got lost for whatever reason there is
> > currently no way to recover from that.
> 
> I am wondering if this is a matter of tasks being cancelled rather than
> being deferred.
> 
> E.g. if the resource gets an "item add" change replay and just can't
> complete it due to network error. If it calls cancelTask then this change
> is gone from the change recorder but the item remains in Akonadi without
> remoteId, right?

That is correct, in theory, just that the implementation defers tasks in case 
of network errors IIUC (cf. resourcetask.cpp, DeferIfNoSession). We cancel 
tasks in case the server replied with an error code. This is indeed a possible 
reason for RID-less items.

> I guess the problem with deferring is that this effectively holds all other
> operations as well.

Yep, and that's the reason why we cancel, if the server rejects an item that 
is usually a persistent error where retrying is pointless (quota being a 
complex counter example). Transient errors like network problems should not be 
handled by canceling though.

> E.g. if you cannot add an item because you've reached the quota, you could
> still succeed in all retrieval or move operations.
> 
> > Is this about collections or items, and what exactly does getting
> > "massively confused" mean?
> 
> As Georg already wrote this is about items. I just wanted to add that I've
> seen this come up on kdepim-users as well. IIRC also in the context of IMAP.

Assuming we cannot reproduce this the only idea I have would be improving 
diagnostics in the cancel cases then. Maybe the server is actually rejecting 
these items?

I doubt it's a generic problem with change replay in a no network/unstable 
network setup though, I checked my laptop which quite often is exposed to 
these, and I have a total of 12 RID-less items there, all with UIDs < 1000 
(ie. very old test data, my production IMAP data has UIDs in the range of 100k 
- 1M).

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/20121216/915d44c5/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/