Bug 338570 - Akonadi Dav Resource: Missing Conflict Resolution
Summary: Akonadi Dav Resource: Missing Conflict Resolution
Status: RESOLVED FIXED
Alias: None
Product: Akonadi
Classification: Frameworks and Libraries
Component: DAV Resource (show other bugs)
Version: 4.13
Platform: Gentoo Packages Linux
: NOR normal
Target Milestone: ---
Assignee: kdepim bugs
URL:
Keywords:
: 341333 343152 (view as bug list)
Depends on:
Blocks:
 
Reported: 2014-08-26 10:11 UTC by Till Schäfer
Modified: 2015-08-19 21:49 UTC (History)
8 users (show)

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


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Till Schäfer 2014-08-26 10:11:31 UTC
The Akonadi DAV resource is missing a proper conflict resolution strategy. This causes the resource to fall into a broken state from which the resource never recovers. Only the deletion of the Akonadi cache and the <resource_name>_changes.dat file helps to get the resource up again. 

There is already some more detail in Bug 335090, which originally describes another trigger which causes the resource to fail.
Comment 1 Ingo Ratsdorf 2014-08-31 21:52:08 UTC
The way the resource is designed is the following: 
Say we delete an event from Calendar in KOrganizer:
1) Akonadi calls item-deleted function in resource
2) Resource grabs url and etag and send a delete request to the caldav server together with an if-match header and the stored etag.
3) If everything worked, resource deletes item from akonadi collection

Now comes the tricky bit:
If the above DOES NOT WORK (because the item was changed meanwhile before we sent that delete request), the resource gets a 412 error back from the server and calls its retry function and that does emit broken, offline.

So in order for this to work, we need to introduce conflict resolution handling. Ie in the above, have three exclusive options:
1) ask the user for input
2) delete anyway (we are the boss)
3) reload from server.

This currently does not work as the dav job is not given to the retry function, only the error message. 
In the above example of deleting an element, the resource should probably do (either or):

1) Ask user for input and then do one of the below
2) Server wins: ignore delete request and start new job to retrieve updated item from DAV server - if that fails, either ignore silently or notify user
3) Client wins: Restart the job without the if-match header, delete the item. If that fails, delete item from collection only, and/or notify user
Comment 2 Marco Solieri 2014-09-03 00:25:02 UTC
*** This bug has been confirmed by popular vote. ***
Comment 3 Tim Ruffing 2015-03-16 19:36:18 UTC
I think bug #343152 is a duplicate of this one.
Comment 4 wuselwu 2015-03-17 04:48:24 UTC
Any news on this one?!
Comment 5 Grégory Oestreicher 2015-06-18 21:00:50 UTC
Git commit 44d38d363d6ff7b4f8c892becfb58a0339dbef0e by Grégory Oestreicher.
Committed on 18/06/2015 at 20:59.
Pushed by goestreicher into branch 'KDE/4.14'.

Add simple conflict handling

The conflict dialog will only be shown for local update / remote update
conflicts. For cases where one side deleted the item while it was updated
on the other, the deleting side loses the conflict automatically to prevent
data loss.
Related: bug 335090
FIXED-IN: 4.14.10

M  +30   -0    resources/dav/common/davitemdeletejob.cpp
M  +13   -0    resources/dav/common/davitemdeletejob.h
M  +5    -4    resources/dav/common/davitemfetchjob.cpp
M  +2    -3    resources/dav/common/davitemfetchjob.h
M  +32   -2    resources/dav/common/davitemmodifyjob.cpp
M  +13   -0    resources/dav/common/davitemmodifyjob.h
M  +5    -0    resources/dav/common/davjobbase.cpp
M  +5    -0    resources/dav/common/davjobbase.h
M  +168  -8    resources/dav/resource/davgroupwareresource.cpp
M  +8    -0    resources/dav/resource/davgroupwareresource.h

http://commits.kde.org/kdepim-runtime/44d38d363d6ff7b4f8c892becfb58a0339dbef0e
Comment 6 Grégory Oestreicher 2015-06-25 21:32:24 UTC
*** Bug 343152 has been marked as a duplicate of this bug. ***
Comment 7 Grégory Oestreicher 2015-08-19 21:49:15 UTC
*** Bug 341333 has been marked as a duplicate of this bug. ***