Bug 341998 - Akonadi Dav Resource looses calendar and settings
Summary: Akonadi Dav Resource looses calendar and settings
Alias: None
Product: Akonadi
Classification: Frameworks and Libraries
Component: DAV Resource (show other bugs)
Version: unspecified
Platform: Gentoo Packages Linux
: NOR normal (vote)
Target Milestone: ---
Assignee: kdepim bugs
Depends on:
Reported: 2014-12-18 10:57 UTC by Till Schäfer
Modified: 2016-02-07 17:30 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:

displayed warning (25.76 KB, image/png)
2014-12-18 10:58 UTC, Till Schäfer

Note You need to log in before you can comment on or make changes to this bug.
Description Till Schäfer 2014-12-18 10:57:10 UTC
Sometimes some (but not all) of my configured calendars are not displayed and recognized anymore by akonadi. After a restart of akonadi the calendar is back, but all are settings lost (e.g. color settings, reminder settings). 

I have observed this bug on several machines with the same calendar, which resides on a davical server (version 1.1.1) 

The bug seem to happen most of the times directly after starting the machine. 

Often, but not always the bug goes along with a warning box "Error while trying to delete calendar item. Error was. Not items found".  (see screenshot)

This bug started to occur in 4.14.0 and is still present in 4.14.3.

Reproducible: Sometimes

akonadi status gave me this result in the broken state: 

$ akonadictl status
Akonadi Control: running
Akonadi Server: running
search paths:  ("/usr/lib64/kde4/plugins", "/home/till/.kde4/lib64/kde4/plugins/", "/usr/lib64/kde4/plugins/", "/usr/lib64/qt4/plugins", "/usr/bin", "/home/till/.kde4/lib64/kde4/", "/usr/lib64/kde4/") 
Akonadi Server Search Support: available (Remote Search, Akonadi Baloo Search Plugin)
Available Agent Types: akonadi_akonotes_resource, akonadi_archivemail_agent, akonadi_baloo_indexer, akonadi_birthdays_resource, akonadi_contacts_resource, akonadi_davgroupware_resource, akonadi_folderarchive_agent, akonadi_followupreminder_agent, akonadi_ical_resource, akonadi_icaldir_resource, akonadi_imap_resource, akonadi_invitations_agent, akonadi_kabc_resource, akonadi_kalarm_dir_resource, akonadi_kalarm_resource, akonadi_kcal_resource, akonadi_kdeaccounts_resource, akonadi_knut_resource, akonadi_localbookmarks_resource, akonadi_maildir_resource, akonadi_maildispatcher_agent, akonadi_mailfilter_agent, akonadi_mailtransport_dummy_resource, akonadi_mbox_resource, akonadi_migration_agent, akonadi_mixedmaildir_resource, akonadi_nepomuk_feeder, akonadi_newmailnotifier_agent, akonadi_nntp_resource, akonadi_notes_resource, akonadi_openxchange_resource, akonadi_pop3_resource, akonadi_sendlater_agent, akonadi_vcard_resource, akonadi_vcarddir_resource
Comment 1 Till Schäfer 2014-12-18 10:58:11 UTC
Created attachment 90034 [details]
displayed warning
Comment 2 Till Schäfer 2015-04-15 10:02:42 UTC
This bug is still valid for 4.14.6 and akonadiserver 1.13.0. 

Furthermore, the deletion message seems to be fixed, but the problem described here still exist.
Comment 3 Till Schäfer 2015-04-15 10:05:08 UTC
One further thing i have noticed: The resource, which goes down is the only writable resource.
Comment 4 Michael Kiefer 2015-05-20 05:22:30 UTC
I experience the same behavior on kde 4.14.2 kaonadi 1.13.0 (Debian Jessie) with owncloud 8 as the server. It happens after resuming from suspend.
In order to exclude the problem being caused by the fact that my $home and the configs in there have been growing for years, I created a new user. Same thing there.
Comment 5 Michael Kiefer 2015-05-26 16:27:38 UTC
Reconfiguring my network got rid of the issue!

I had the same thing on debian for over a year, my Owncloud calendar and address book (both of them DAV groupware ressources) disappeared after reboot or resume from suspend.

Some time ago, I was playing around with hostapd, and from that time, I had my network card manually configured as a bridge. Yesterday, I removed the bridge and made network-manager to take care of the connection: now it works.

Stupid networkmanager...
Comment 6 Till Schäfer 2015-06-14 12:59:02 UTC
I have dug a bit deeper into the code and have a question to all people observing this bug: 

Can you see the error message "Unable to fetch collections" in your ~/.xsession-errors ?  Is the occurrence of such string in relation to the described bug?
Comment 7 Grégory Oestreicher 2015-06-25 20:44:32 UTC
Git commit b3bfa11aae9b6d7696bae7de0bf5afdc79a91fba by Grégory Oestreicher.
Committed on 25/06/2015 at 20:42.
Pushed by goestreicher into branch 'KDE/4.14'.

Pre-validation of the collections propfind response

Not sure if this may explain the disappearing collections in some cases
but here goes. Extra validation can't hurt.

M  +19   -1    resources/dav/common/davcollectionsfetchjob.cpp
M  +1    -0    resources/dav/common/davcollectionsfetchjob.h

Comment 8 Till Schäfer 2015-06-26 12:47:54 UTC
THX for the fix. 

I would like to test it, but i am currently stuck here with my setup. I would like to install the updated akonadi resource side by side with my regular one. Maybe you can help me out:

- I have already checked out the 4.14 branch an compiled it. I now have a install folder which contains kdepim-runtime including the akonadi resource. 
- Now i have copied the davgroupwareresource.desktop file and modified the following lines: 
  Name=DAV groupware resource (TESTING)

My wish was that i now can add an extra testing resource in akonadi, But i dont see it. Any suggestions?
Comment 9 Till Schäfer 2015-06-26 12:49:49 UTC
(In reply to Till Schäfer from comment #8)
> - Now i have copied the davgroupwareresource.desktop file and modified the
> following lines: 
under /usr/share/akonadi/agents/
Comment 10 Till Schäfer 2015-06-26 14:23:42 UTC
my issue is resolved misspelled the exec path. i will give a feedback as soon i can see there is a difference.
(it usually taskes some time before the error occurs)
Comment 11 Till Schäfer 2015-06-29 10:22:19 UTC
i am sorry, but the bug occurred again using the current git version.
Comment 12 Grégory Oestreicher 2015-06-29 19:51:54 UTC
OK, do you happen to remember what you did when this occurred again? Anything that would help me reproduce it, because as it stands I'm completely clueless as to how this may happen.
Comment 13 Till Schäfer 2015-06-30 09:59:47 UTC
This time the bug occurred directly after a reboot. That means: after i typed in my password for kwallet, I opened Kontact and the calendar was not there. I have not found a reliable way to trigger it, but it occurs regularly (every 2 or 3 days).  I have also noticed this bug after standby/hibernate and once after i left Kontact running for a ling time without a reboot (2 or 3 weeks). The standby/hibernate problem seems to be fixed, since i am using network manager (see above). The reboot problem is the most frequent one. 

One further thing, that might help. This bug occurred the first time to me in the KDE release directly after the Bug 335090 was hot fixed (Git commit c9a781f5b61813da80a31793bb6ce90b6f2e9046; the broken state fix, not the second fix with missing conflict resolution). Maybe there is some connection here. 

I am willing to further assist you to find the bug. You can provide me with a version that logs every step or something like that. If the bug occurs i will send you the log files and the exact time of occurrence.
Comment 14 Till Schäfer 2015-07-02 09:49:17 UTC
a few further informations: 
-> I have a single resource with several calendars, but only a single calendar vanishes and loses the settings. The problematic calendar is the only writeable calendar of the resource. 
-> I had two resources configured, pointing at the same calendar, during the test of your patch. The bug occurred simultaneously for both resources. Therefore, there seems to be a resource independent trigger for the bug. 
- The davical server lives on my home internet connection with a 24 hour IP address renewal. As I have seen the bug today again (on my work computer, which is outside my home network) after letting the resource run for a longer time (>24h), I was asking myself if there is a relation between a temporarily unavailable server and the occurrence of this bug.
Comment 15 Grégory Oestreicher 2015-08-10 21:02:35 UTC
Git commit 3122234bb6a3f3690a8f4f90dae5931d27423756 by Grégory Oestreicher.
Committed on 10/08/2015 at 21:01.
Pushed by goestreicher into branch 'Applications/15.08'.

Forward the principal fetch job response code

This may explain the disappearing collections problem if
the principal fetch job times out but the subsequent
collections discovery jobs don't and return an empty set.

M  +14   -7    resources/dav/common/davcollectionsfetchjob.cpp
M  +2    -1    resources/dav/common/davprincipalhomesetsfetchjob.cpp
M  +2    -1    resources/dav/common/davprincipalhomesetsfetchjob.h

Comment 16 Grégory Oestreicher 2015-08-29 22:14:01 UTC
Git commit 87dfde58b2169b1f083c6f2e7d314af03477e46a by Grégory Oestreicher.
Committed on 29/08/2015 at 22:13.
Pushed by goestreicher into branch 'Applications/15.08'.

Also forward errors when the principal fetch job fails

M  +2    -0    resources/dav/common/davcollectionsfetchjob.cpp

Comment 17 Grégory Oestreicher 2016-02-07 17:30:45 UTC
IIRC this was fixed following a private exchange with Till, but feel free to reopen if I misremember.