The dav ressource falls into a offline/broken state if I delete a single item of a event series. Reproducible: Always Steps to Reproduce: 1. Add an event series to the dav ressource (radicale server in this case) with start date, end date and some exceptions 2. delete an occurence of the event of the series in the agenda-view of korganizer 3. the dav resource falls into offline/broken state. the only way to recover this is to delete the ressource and re-add it. Actual Results: the dav ressource is offline/broken permanently Expected Results: well.. this is obvious. the dav ressource should not fall into a not-recoverable state. critical, as all changes made to the ressource are not synced to the server after that fail, which can lead to data loss.
*** This bug has been marked as a duplicate of bug 397408 ***
*** Bug 397408 has been marked as a duplicate of this bug. ***
This has been fixed for me with 5.9.3. Can you report back whether you still encounter this problem? (BTW, the bug marked as a duplicate of this one did not mention the fact that an event series was involved and neither was that the case for me.)
The issue with the broken state after deletion seems to be fixed, however the removed item of the series is not synced anymore at all if it was removed within KOrganizer. The other way round (deleting an item of a series in e.g. on my phone) everything works fine. But there seems to be a new incarnation of that issue: 1. Add a new event to a dav ressource (in my case a self hosted Radicale instance): e.g. 12.12.2018 13:00-14:00, repeat weekly, end after 5 times, excluding 26.12.2018. 2. Sync that ressource. It does not show "broken" but stays in "Online, Running (0%)" forever. The ressource stops syncing anything. State in the Akonadi Console for this ressource is: ResourceScheduler: Online current task: 2 ChangeReplay queue 0 is empty queue 1 is empty queue 2 is empty queue 3 is empty queue 4 1 tasks: 10 SyncAll A way to recover from this is to toggle the ressource offline in akonadi, abort the activity, delete the event series in korganizer, toggle the ressource online again in the akonadi console. Afterwards the ressource syncs fine again. Akonadi/KOrganzier 5.8.3
In reply to Tom Mittelstädt from comment #4) > Akonadi/KOrganzier 5.8.3 Hmm, I know that something was fixed between and 5.9.3. But I can understand that you may not be able to update. The rest of your description is somewhat similar to my experiences these last few days. The following approach resulted in the setup working (although I still fear it may break at any time): 0. remove the problematic resource 1. akonadictl fsck (in a console; see akonadictl help for some info) 2. akonadictl vacuum (in a console; see akonadictl help for some info) 3. re-create the resource (I split contacts/calendars into two separate resources as well, so that one doesn't block the other if there is trouble.) If that does not fix it, there is another thing you can have a look at: In the DB console of akonadiconsole (queries entered below, execution button on the right, results above), execute show create table pimitemtable; You'll have to copy the result value to a file to be able to view it all. In case there is something like '0000-00-00 00:00:00' somewhere, report back.
> Hmm, I know that something was fixed between and 5.9.3. > But I can understand that you may not be able to update. I'm going to set up a KDE Neon VM (to get a more recent version and to have a "clean" system for testing purposes) and call back (as I stopped using KOrganizer 2 years ago/use it only read-only for the PIM Event Plugin) as it regularly "silently" messed up my work calendars).
Created attachment 116871 [details] logs-adding-event
Created attachment 116872 [details] logs-during-ressource-restart
Fresh KDE Neon installed from current iso $ sudo apt update && sudo apt dist-upgrade -y && sudo apt install korganizer -y && sudo systemctl reboot -i $ akonadictl --version akonadictl 5.9.3 KOrganizer > Add DAV-Groupware ressource > Credentials (check) > manual > add CalDAV > address (https://.../radicale/) > use global credentials > discover collections > OK Add the event series described in #4 The behaviour is the same as in #4 So I took a look into the server logs and I guess I found kinda "reason": see "logs-adding-event"-attachment So the dav ressource tries to make a PUT request for the event series that is answered with 400 Bad Request, gets an 404 response and is freezing in this state until the event that caused that 400 answer is deleted. see "logs-during-ressource-restart"-attachment I'm not sure if this is a bug in the ressource or in radicale, but the ressource should not fail silently if there is an error.
Sorry for spamming; I've overlooked the reason in the server logs for the 400 answer: WARNING: Bad PUT request on '/tom/Privat/1544608970.R271.ics': Failed to store item '1544608970.R271.ics' in collection 'tom/Privat': can't compare offset-naive and offset-aware datetimes
(In reply to Tom Mittelstädt from comment #9) > I'm not sure if this is a bug in the ressource or in radicale, but the > ressource should not fail silently if there is an error. At least that. I'm at a loss and can't help with further suggestions. The fact that you used KDE Neon and the ample information you provide should be a good starting point for a developer. I'm updating the bug properties (severity to grave, as things just don't work; critical is for data loss, I recall, which you do not have here, I think). In case a developer does take on this bug (do not rely on that), would you be able and willing to provide them with a test account on your server?
Created attachment 116874 [details] radicale-debug-log The radicale log for the described event. Compared to all other dates/timestaps EXDATE seems to be missing some information? BEGIN:VEVENT DTSTAMP:20181212T103753Z CREATED:20181212T103753Z UID:1a20e267-e8b4-492a-a98d-776c96f82bcc LAST-MODIFIED:20181212T103753Z SUMMARY:test-entry RRULE:FREQ=WEEKLY;COUNT=5;BYDAY=WE EXDATE;VALUE=DATE:20181226 DTSTART;TZID=Europe/Berlin:20181212T130000 DTEND;TZID=Europe/Berlin:20181212T140000 TRANSP:OPAQUE END:VEVENT
(In reply to Erik Quaeghebeur from comment #11) > In case a developer does take on this bug (do not rely on that), would you > be able and willing to provide them with a test account on your server? of course :)