Bug 335833

Summary:	Akonadi Dav Resource: Broken State / Resource cannot be deleted (401)
Product:	[Frameworks and Libraries] Akonadi	Reporter:	Till Schäfer <till2.schaefer>
Component:	DAV Resource	Assignee:	kdepim bugs <kdepim-bugs>
Status:	RESOLVED FIXED
Severity:	normal	CC:	cmdln, greg, herr_oswald, kde.bugzilla.2012, luisfe, matija, ml, sebastian.niemeyer
Priority:	NOR
Version:	4.13
Target Milestone:	---
Platform:	Gentoo Packages
OS:	Linux
Latest Commit:		Version Fixed In:
Sentry Crash Report:
Attachments:	agent_config_akonadi_davgroupware_resource_17_changes.dat

Description Till Schäfer 2014-06-05 12:17:39 UTC

DAV Resource falls into an unrecoverable state after deleting todo items that where already deleted on the server side.

this bug is related to 

Reproducible: Always

Steps to Reproduce:
1. create a todo
2. delete that todo on computer A
3. event is not deleted on computer B because of Bug 328734
4. delete event on computer B
Actual Results:  
DAV Resource is in broken, offline state and never comes up again. The error message is: 

Bei der Abfrage ist ein Problem aufgetreten. Der Eintrag wurde nicht vom Server gelöscht. Die Ressource kann nicht gelöscht werden. (401).

English translation: 
An error occured during a query. The entry was not deleted on the server. Resource cannot be deleted (401).

Expected Results:  
Although this bug is following Bug 328734. DAV Resource should detect that the item is already deleted on the server side and correct the synchronization error. 
It should not fail to start after such an error

This bug is also related to Bug 335090, which shows a similar behavior of the DAV resource, but has a different trigger.

Comment 1 Till Schäfer 2014-06-05 12:25:39 UTC

Created attachment 87025 [details]
agent_config_akonadi_davgroupware_resource_17_changes.dat

changes file that causes the bug

Comment 2 Thomas Gideon 2014-07-09 16:38:51 UTC

I see this exact same bug. The only fix I seem to have come up with is to delete the calendars and folder from Kontact completely and re-add. I have tried to use akonadi console to flush the local cache, to remove invalid objects in the local store, re-sync and re-start. Nothing I do in the console ultimately resolves this.

Comment 3 Till Schäfer 2014-07-10 08:50:12 UTC

(In reply to comment #2)
> I see this exact same bug. The only fix I seem to have come up with is to
> delete the calendars and folder from Kontact completely and re-add. I have
> tried to use akonadi console to flush the local cache, to remove invalid
> objects in the local store, re-sync and re-start. Nothing I do in the
> console ultimately resolves this.

beside clearing the cache you have to stop akonadi, remove agent_config_akonadi_davgroupware_resource_XX_changes.dat (where XX is the number of your resource) and restart akonadi afterwards to get the resource up again.

Comment 4 Grégory Oestreicher 2014-08-31 16:52:30 UTC

Git commit c9a781f5b61813da80a31793bb6ce90b6f2e9046 by Grégory Oestreicher.
Committed on 31/08/2014 at 16:43.
Pushed by goestreicher into branch 'KDE/4.14'.

Don't unnecessarily go offline

Check if the error returned by the jobs while creating,
modifying or deleting items are transient or final
and act accordingly.
Related: bug 335090

M  +2    -1    resources/dav/common/davitemcreatejob.cpp
M  +2    -3    resources/dav/common/davitemcreatejob.h
M  +2    -1    resources/dav/common/davitemdeletejob.cpp
M  +2    -3    resources/dav/common/davitemdeletejob.h
M  +2    -1    resources/dav/common/davitemmodifyjob.cpp
M  +2    -3    resources/dav/common/davitemmodifyjob.h
A  +84   -0    resources/dav/common/davjobbase.cpp     [License: GPL (v2+)]
A  +78   -0    resources/dav/common/davjobbase.h     [License: GPL (v2+)]
M  +1    -0    resources/dav/resource/CMakeLists.txt
M  +20   -3    resources/dav/resource/davgroupwareresource.cpp

http://commits.kde.org/kdepim-runtime/c9a781f5b61813da80a31793bb6ce90b6f2e9046

Comment 5 Haley S. 2014-09-02 08:07:40 UTC

*** This bug has been confirmed by popular vote. ***

Comment 6 Grégory Oestreicher 2014-09-30 18:49:59 UTC

This must've been fixed in 4.14.1, but feel free to reopen if I'm wrong.

Cheers,
Grégory