Bug 285632 - No recovery for items without remote id for which the initial synchronization failed
Summary: No recovery for items without remote id for which the initial synchronization...
Status: RESOLVED UNMAINTAINED
Alias: None
Product: Akonadi
Classification: Frameworks and Libraries
Component: general (show other bugs)
Version: unspecified
Platform: Fedora RPMs Linux
: NOR normal
Target Milestone: ---
Assignee: kdepim bugs
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-11-03 10:41 UTC by Georg Greve
Modified: 2017-01-07 22:23 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Georg Greve 2011-11-03 10:41:50 UTC
Version:           unspecified (using KDE 4.7.2) 
OS:                Linux

Sometimes items in Akonadi end up without a remote ID.

One way in which I manage to create this semi-regularly is: Create new event. Realize it's been saved in the wrong calendar, or at least suspect it's been saved to the wrong calendar, re-open for editing immediately (while the item is still not saved to the server) and change (or not change) the folder, save.

Typically this will then bring up the conflict dialog, in which I select the latest version, but ultimately that is then never saved to the server.

Result: An item in the local akonadi database does not have a remote id. This does not halt other items, which get synchronized normally, but you'll end up with some items that do not have remote ids.

It is likely possible to create the same situation in different ways.

While it would be good to handle the initial scenario better, the biggest issue is that Akonadi cannot recover from this scenario, as even an edit won't save the item back to the server, since it cannot be found on the server.

So Akonadi needs a recovery path for situations where there is no remote id for an object.

Reproducible: Sometimes

Steps to Reproduce:
Try the above, or just delete the remote ID in the Akonadi database.


Expected Results:  
Akonadi should have recognized that it has items without remote id, and tried to write them to the server again.
Comment 1 Georg Greve 2011-11-03 10:42:45 UTC
Adding Volker on his own request.
Comment 2 Denis Kurz 2016-09-24 20:40:43 UTC
This bug has only been reported for versions older than KDEPIM 4.14 (at most akonadi-1.3). Can anyone tell if this bug still present?

If noone confirms this bug for a recent version of akonadi (part of KDE Applications 15.08 or later), it gets closed in about three months.
Comment 3 Denis Kurz 2017-01-07 22:23:16 UTC
Just as announced in my last comment, I close this bug. If you encounter it again in a recent version (at least 5.0 aka 15.08), please open a new one unless it already exists. Thank you for all your input.