I just tried to start KOrganizer after few days and it asserted, because two events from the Facebook resource don't have UID stored in payload (and remoteID is empty as well) The body part looks like this: BEGIN:VCALENDAR PRODID:-//K Desktop Environment//NONSGML libkcal 3.2//EN VERSION:2.0 BEGIN:VEVENT DTSTAMP:-4713010T000000 CREATED:-4713010T000000 DESCRIPTION;X-KDE-TEXTFORMAT=HTML:<a href=\"http: //www.facebook.com/event.php?eid=\">View Event on Facebook</a> TRANSP:OPAQUE END:VEVENT END:VCALENDAR Reproducible: Didn't try
I removed the resource and added it again and it's 100% reproducible. There are only two items in the "Events" collection, both are corrupted. From my Google Calendar experience this usually means a problem with the parser ;-)
Indeed the server is returning an error ("Unknown error") instead of the events.
Further investigation shows we request too many ids at once, if the amount is tuned down, we get proper data.
Git commit ea9700409f1d5d773f611490566c23ccd8f57814 by Martin Klapetek. Committed on 20/03/2013 at 20:04. Pushed by mklapetek into branch 'master'. Limit how many ids we can query at once It turns out that querying for too many ids at once make Facebook servers unhappy, so we artificially limit it on the job level, 15 looks to be ok, so process 15 ids, then 15 more etc and only then emit the job result. Reviewed-by: Dan Vratil M +42 -5 libkfbapi/facebookjobs.cpp http://commits.kde.org/libkfacebook/ea9700409f1d5d773f611490566c23ccd8f57814
Git commit a285c8325ec29c63e1ec6375ab3b307f4bf08c6e by Martin Klapetek. Committed on 20/03/2013 at 20:17. Pushed by mklapetek into branch 'master'. Make sure we don't store invalid events from Facebook M +4 -0 resources/facebook/facebookresource_events.cpp http://commits.kde.org/kdepim-runtime/a285c8325ec29c63e1ec6375ab3b307f4bf08c6e
Am Mittwoch, 20. März 2013, 19:04:41 schrieb Martin Klapetek: > Limit how many ids we can query at once > > It turns out that querying for too many ids at once make Facebook > servers unhappy, so we artificially limit it on the job level, > 15 looks to be ok, so process 15 ids, then 15 more etc and only > then emit the job result. you have a typo in the comment - it says 10 instead of 15
Oops, sorry. It was initially 10, then I raised to to 15.