Bug 307746

Summary: Sync error: Items requested for an unknown collection
Product: [Frameworks and Libraries] Akonadi Reporter: Unknown <null>
Component: DAV ResourceAssignee: kdepim bugs <kdepim-bugs>
Status: RESOLVED FIXED    
Severity: normal CC: andreas.grundler, andreas, arne, becheru.petru.ioan, cfeck, david001, dns_hmpf, ebreiss, greg, grzegorz.kubiak, heri+kde, himself, info, ingo, jonathand131, kde-bugs, kde, lnxusr, matthieu, mss, nickbryda, pete, rack, richard.ruzsa, sebastian, severin.weingarten, shadow.walker, shura01, stephan.diestelhorst, talmage, third-impact, thorsten.schnebeck
Priority: NOR    
Version: 4.9   
Target Milestone: ---   
Platform: openSUSE   
OS: Linux   
Latest Commit: Version Fixed In: 4.9.3
Sentry Crash Report:
Attachments: Non-fix, just a "silencer".
Screenshot of the KMail autocompletion addressbook sources
Fix by revert

Description Unknown 2012-10-02 19:33:28 UTC
I created a local CalDAV server with Radicale and 2 later days KOrganizer started to throw error messages.

Every time it tries to sync, KDE reports the following: "Items requested for an unknown collection". It seems KOrganizer is able to sync (I can see the new event on my mobile phone) but only with this error message.

I have a WireShark capture, if it's needed I can upload it.

KDE version: 4.9.2.

Reproducible: Always
Comment 1 Sebastian Voitzsch 2012-10-03 22:24:40 UTC
Same here, but with a davical calendar/addressbook store.

I updated to 4.9.2 this evening, after the update I receive the notifications every 5 mins (i.e., per sync). I get two messages for the caldav (calendar) and the carddav (addressbook) store.

I deleted and recreated the akonadi ressources, but this did not change anything. Server wasn't changed, my other devices (Android tablet and phone) can sync without any trouble. Syncing works, only the annoying notifications.

.xsession-errors says "akonadi_davgroupware_resource_7(3020): Can't find a configured URL, collection.remoteId() is  "akonadi_davgroupware_resource_7" 

The second source gives the same error but with "akonadi_davgroupware_resource_8".
Comment 2 Gauss 2012-10-04 08:08:26 UTC
Same problem here when syncing with Google calendar. It started with an update to KDE 4.9.2 this morning and since then the message pops up every few minutes.
Comment 3 Florent C. 2012-10-05 06:14:08 UTC
Hi,

Same problem here with ownCloud sync (caldav + carddav). Pretty annoying.
KDE 4.9.2
Kubuntu 12.04.1
Comment 4 Severin Weingarten 2012-10-05 09:00:48 UTC
Same here.
KDE 4.9.2
Kubuntu 12.04.1
Comment 5 andreas.grundler 2012-10-05 09:38:44 UTC
Same here.

Owncloud 4.0.7
KDE 4.9.2
Kubuntu 12.04.1
Comment 6 Severin Weingarten 2012-10-05 09:57:13 UTC
(In reply to comment #4)
> KDE 4.9.2
> Kubuntu 12.04.1
Forgot: Owncloud 4.0.7
Comment 7 Claus-Justus Heine 2012-10-05 15:06:49 UTC
Created attachment 74360 [details]
Non-fix, just a "silencer".

Hi,

here comes a non-fix, but a silencer. The problem is either

* retrieveItems() is called with something which is not a collection

or

* some collections carry the bogus remoteId() "akonadi_davgroupware_resource_XX" which actually is just a local id.
Comment 8 Arne K. Haaje 2012-10-08 17:04:20 UTC
I can confirm this happened after upgrading to KDE version: 4.9.2 on Kubuntu 12.04. It happens with both calendar and addressbook. 

Watchign the logs on my Davical server, I see that the error occur because the username is not supplied on the first request. Kontact then add the username and sync is done. However, it still keep sending the request without username, so the error message reappear.

When configuring the account it makes no difference if I use global or local username.

From my logs;

10.0.0.13 - - [07/Oct/2012:17:51:32 +0200] "PROPFIND /kalender/caldav.php/myUsername/adresser/ HTTP/1.1" 401 5947 "-" "Mozilla/5.0 (X11; Linux x86_64) KHTML/4.9.2 (like Gecko) Konqueror/4.9"
10.0.0.13 - - [07/Oct/2012:17:51:32 +0200] "PROPFIND /kalender//caldav.php/ HTTP/1.1" 401 5947 "-" "Mozilla/5.0 (X11; Linux x86_64) KHTML/4.9.2 (like Gecko) Konqueror/4.9"
10.0.0.13 - myUsername [07/Oct/2012:17:51:32 +0200] "PROPFIND /kalender/caldav.php/myUsername/adresser/ HTTP/1.1" 207 6267 "-" "Mozilla/5.0 (X11; Linux x86_64) KHTML/4.9.2 (like Gecko) Konqueror/4.9"
10.0.0.13 - myUsername [07/Oct/2012:17:51:32 +0200] "PROPFIND /kalender//caldav.php/ HTTP/1.1" 207 6251 "-" "Mozilla/5.0 (X11; Linux x86_64) KHTML/4.9.2 (like Gecko) Konqueror/4.9"
10.0.0.13 - - [07/Oct/2012:17:51:32 +0200] "PROPFIND /kalender/caldav.php/arne%40drlinux.no/ HTTP/1.1" 401 5947 "-" "Mozilla/5.0 (X11; Linux x86_64) KHTML/4.9.2 (like Gecko) Konqueror/4.9"
10.0.0.13 - - [07/Oct/2012:17:51:32 +0200] "PROPFIND /kalender/caldav.php/arne%40drlinux.no/ HTTP/1.1" 401 5947 "-" "Mozilla/5.0 (X11; Linux x86_64) KHTML/4.9.2 (like Gecko) Konqueror/4.9"
10.0.0.13 - myUsername [07/Oct/2012:17:51:33 +0200] "PROPFIND /kalender/caldav.php/arne%40drlinux.no/ HTTP/1.1" 207 6427 "-" "Mozilla/5.0 (X11; Linux x86_64) KHTML/4.9.2 (like Gecko) Konqueror/4.9"
10.0.0.13 - myUsername [07/Oct/2012:17:51:33 +0200] "PROPFIND /kalender/caldav.php/arne%40drlinux.no/ HTTP/1.1" 207 6811 "-" "Mozilla/5.0 (X11; Linux x86_64) KHTML/4.9.2 (like Gecko) Konqueror/4.9"
10.0.0.13 - - [07/Oct/2012:17:51:33 +0200] "PROPFIND /kalender/caldav.php/myUsername/adresser/ HTTP/1.1" 401 5947 "-" "Mozilla/5.0 (X11; Linux x86_64) KHTML/4.9.2 (like Gecko) Konqueror/4.9"
10.0.0.13 - - [07/Oct/2012:17:51:33 +0200] "REPORT /kalender/caldav.php/myUsername/kalender/ HTTP/1.1" 401 5947 "-" "Mozilla/5.0 (X11; Linux x86_64) KHTML/4.9.2 (like Gecko) Konqueror/4.9"
Comment 9 Ingo Ratsdorf 2012-10-12 08:34:11 UTC
Well, that the first request does not contain a username is normal and expected. That's how auth works. You try, get rejected and supply pw/user.

I can confirm that the error only occured after upgrade from KDE 4.9.1 to 4.9.2.

More importantly I noticed that now all DAV collections in KOrganiser have a tickbox as if they were calendars themselves, which was nt the case in 4.9.1. It does not matter whether you switch them on or off, you cannot create items in them, since they are merely empty dummy collection folders. However I believe that Akonadi tries to sync them, which of course does not work.
Fact is that I am not even getting any error anywhere in my server logs, which means that the DAV resource is not even trying to access any server for it.
Ergo the error must be somewhere between Akonadi and DAV resource, or between the client (KAddressbook|KOrganizer) and Akonadi.
Maybe Gregory has some ideas and can do some debugging but I suspect it's an error in Akonadi.
Comment 10 christian tacke 2012-10-12 15:07:24 UTC
Same with me. Anyway to help debugging this? I don't have sources right know, but anything from that I'm willing to help.
Comment 11 Ingo Ratsdorf 2012-10-12 20:56:47 UTC
Created attachment 74507 [details]
Screenshot of the KMail autocompletion addressbook sources

Have found another interesting hint: Addressbook autocompletion now has two more "Addressbooks": The top level DAV folders. This was no there before KDE 4.9.2....
Attached screenshot.
Comment 12 christian tacke 2012-10-13 08:06:11 UTC
I just checked the KMail autocompletion settings and expected it to look just like Ingo's attachment - but it didn't. Then I noticed that I didn't hear or see anything of that error since a while. I checked and noticed I lost the connection to the server (I have a local ownCloud and resolve the hostname via avahi). Even the check mark next to the folder vanished.

As soon as avahi redetected it an I triggered a manual update and voila - the check mark appeared again and the error was shown.

Hope that helped.
Comment 13 Andreas Pietzowski 2012-10-13 10:47:08 UTC
Same annoying error pop-ups here every 5 minutes with KDE 4.9.2 and a normally working caldav server. Other clients can sync without error messages.
Comment 14 Sebastian Voitzsch 2012-10-13 11:07:36 UTC
Reported on 10/2, annoying error messages all day long, many confirmations on several distros.

Still "status: unconfirmed"? 

As for the "non-fix, just a silencer" - where can I find the file to apply the patch to? I tried "apt-get source akonadi-server", but couldn't find the mentioned files. Also "apt-get source libakonadi-calendar4" wasn't successful.

In addition, I tried to get rid of the messages by disabling "application notifications" in the plasma notification widget. But this only made the messages appear in the center of the screen and no more in the notification widget.

Sebastian
Comment 15 christian tacke 2012-10-13 17:16:22 UTC
I think Ingo already nailed it where the error seem's to be located which matches which what Claus-Justus said and I noticed. retrieveItem() with something that is not an collection, which the containing folder is not. Sadly I don't know where to look in the code.
Comment 16 gramb 2012-10-13 18:18:05 UTC
*** This bug has been confirmed by popular vote. ***
Comment 17 Christoph Feck 2012-10-15 11:01:30 UTC
*** Bug 307779 has been marked as a duplicate of this bug. ***
Comment 18 David Weber 2012-10-15 12:53:47 UTC
Created attachment 74557 [details]
Fix by revert

Reverting 0ecdc1c34082224fff5f360b2d6c9a7bfe8c7ac3 fixes the problem for me.
But I guess we need a better solution than just reverting it

http://quickgit.kde.org/index.php?p=kdepim-runtime.git&a=commit&h=0ecdc1c34082224fff5f360b2d6c9a7bfe8c7ac3
Comment 19 Ingo Ratsdorf 2012-10-15 17:01:01 UTC
No idea how Akonadi and co. work, however I think that I have to agree with the revert. It seems strange to have the parent collection (ie DAV folder) having all the mime types of all child collections. That would effectively tell Akonadi that the DAV parent folder has toDos and Calendar Entries as well as Address Books? Seems strange, since it's only a collection of collections not items.... so the one and only mimetype should be "directory" or whatever the mime type for it is.
If that does not show up somewhere in KOrganiser, then KOrganiser needs to be fixed maybe by querying child-collections instead of root collections.

Just my thought.
Comment 20 Christoph Feck 2012-10-16 20:34:24 UTC
*** Bug 308509 has been marked as a duplicate of this bug. ***
Comment 21 Grégory Oestreicher 2012-10-17 21:14:23 UTC
Git commit 5e7db58608f39bceb94ff421abd48729cc46cf72 by Gregory Oestreicher.
Committed on 17/10/2012 at 23:12.
Pushed by goestreicher into branch 'master'.

Don't call cancelTask() when an invalid collection is given

The behavior introduced by 0ecdc1c34082224fff5f360b2d6c9a7bfe8c7ac3
caused a spurrious notification at each sync. Now just return
an empty items list.

M  +2    -2    resources/dav/resource/davgroupwareresource.cpp

http://commits.kde.org/kdepim-runtime/5e7db58608f39bceb94ff421abd48729cc46cf72
Comment 22 Thorsten Schnebeck 2012-10-18 06:33:31 UTC
> Pushed by goestreicher into branch 'master'

What about backporting into 4.9 branch?

Bye

  Thorsten
Comment 23 Grégory Oestreicher 2012-10-18 06:37:10 UTC
Hi,

> What about backporting into 4.9 branch?

Done here: https://projects.kde.org/projects/kde/kdepim-runtime/repository/revisions/5e40280e8ec9e39d65b3b1a4e5ebecc4e62f8863

I haven't Cc'ed this bug report for the backport.

Cheers,
Grégory
Comment 24 Christoph Feck 2012-11-01 21:27:30 UTC
*** Bug 309358 has been marked as a duplicate of this bug. ***
Comment 25 lnxusr 2013-04-05 18:11:17 UTC
This is back in KDE 4.10.2 in Kubuntu 12.10.  I upgraded last night and this (Google Calendar: Asked to retrieve items for an unknown collection:) pops up every 5 min.

Should I try the revert mentioned above?
Comment 26 Grégory Oestreicher 2013-04-05 18:26:45 UTC
Could you try by re-creating the resource?
Comment 27 lnxusr 2013-04-05 20:25:26 UTC
(In reply to comment #26)
> Could you try by re-creating the resource?

Thanks Grégory, that seems to have done the trick, although in a bit of a strange way.  When I deleted the original calendar resource, I got an (actually several) error dialog saying it couldn't delete the folder or something to that effect, but the calendar was removed from the list.  I created a new calendar but it didn't seem to be syncing with google so I exited Kontact and restarted.  The original resource was back and the new one still refused to sync.  The original error no longer occurs, so I deleted the newly created resource and have yet to see the 'unknown collection' error.