Baikal icon indicating copy to clipboard operation
Baikal copied to clipboard

Server 500 if no valid instances

Open ANEast opened this issue 2 years ago • 4 comments

Baikal version: 0.6.1

I am using a mixture of software to access a CalDav. Mostly it works very well. However, I have found one issue which I'm not sure where the correct place is to report it - so please advise me if this is not an error in Baikal where you think the error lies.

The software stack for the error is Android 9 with DAVx5 3.3.12-ose and aCalendar+ 2.5.3

It appears slightly hard to reproduce - partly because it relies on syncing and I'm too impatient when testing. However, essentially if I create a recurring event, then change one of the dates so that it is a separate event (edit only this occurence), then delete the recurring portion and the stand-alone portion, (all within aCalendar+) Baikal issues a 500 server error.

The biggest issue is that I now have no event on Android, and DAVx5 will keep trying to delete the event indefinitely. The only way to get out of the loop is to go into another device, and change the event (which hasn't been deleted due to the server error) so that the server version is now newer than the original android version and a sync forces an update of the original device.

I don't know if it is related, but the standalone event seems to retain a RRule (though it not longer repeats) and the repeat is no longer editable in aCalendar+.

The 500 seems to be generated as there are "no valid instances". However, it seems strange to me that this generates a 500, rather than simply deleting the event. Am I missing something. Surely "no valid instances" = "event deleted". It would appear not in Baikal.

Baikal Stack Trace: [27-Aug-2021 23:44:21 Europe/London] Sabre\VObject\Recur\NoInstancesException: This recurrence rule does not generate any valid instances in PATH\baikal\vendor\sabre\vobject\lib\Recur\EventIterator.php:192 Stack trace: #0 PATH\baikal\vendor\sabre\dav\lib\CalDAV\Backend\PDO.php(657): Sabre\VObject\Recur\EventIterator->__construct(Object(Sabre\VObject\Component\VCalendar), '53ad89ae-082c-4...') #1 PATH\baikal\vendor\sabre\dav\lib\CalDAV\Backend\PDO.php(595): Sabre\CalDAV\Backend\PDO->getDenormalizedData('BEGIN:VCALENDAR...') #2 PATH\baikal\vendor\sabre\dav\lib\CalDAV\CalendarObject.php(107): Sabre\CalDAV\Backend\PDO->updateCalendarObject(3, '53ad89ae-082c-4...', 'BEGIN:VCALENDAR...') #3 PATH\baikal\vendor\sabre\dav\lib\DAV\Server.php(1133): Sabre\CalDAV\CalendarObject->put('BEGIN:VCALENDAR...') #4 PATH\baikal\vendor\sabre\dav\lib\DAV\CorePlugin.php(515): Sabre\DAV\Server->updateFile('calendars/MyCal...', 'BEGIN:VCALENDAR...', NULL) #5 PATH\baikal\vendor\sabre\event\lib\WildcardEmitterTrait.php(96): Sabre\DAV\CorePlugin->httpPut(Object(Sabre\HTTP\Request), Object(Sabre\HTTP\Response)) #6 PATH\baikal\vendor\sabre\dav\lib\DAV\Server.php(464): Sabre\DAV\Server->emit('method:PUT', Array) #7 PATH\baikal\vendor\sabre\dav\lib\DAV\Server.php(241): Sabre\DAV\Server->invokeMethod(Object(Sabre\HTTP\Request), Object(Sabre\HTTP\Response)) #8 PATH\baikal\vendor\sabre\dav\lib\DAV\Server.php(309): Sabre\DAV\Server->start() #9 PATH\baikal\Core\Frameworks\Baikal\Core\Server.php(123): Sabre\DAV\Server->exec() #10 PATH\baikal\html\dav.php(61): Baikal\Core\Server->start()

Really appreciate your pointers and thoughts.

Many thanks.

ANEast avatar Aug 27 '21 22:08 ANEast

I can confirm this issue. I already did some research about it a few weeks ago and found the following: https://github.com/nextcloud/server/issues/5641 https://forums.bitfire.at/topic/1024/owncloud-this-recurrence-rule-does-not-generate-any-valid-instances

The only way to "fix" it is by identifying the "defective" calendar entries who have a recurrence rule set which doesn't create any instances. Then just delete it on client or on server side and restart the sync. The sync fails because the entry is already available on the server and on the client. Because neither the one on the server nor the one on the client gets automatically deleted it blocks the whole sync process with error 500.

As we are using Baikal and the calendar apps for years now I conclude this "issue" got intoduced by some Baikal update or by some changes in Androids calendar app (or some of the third-party ones). I don't think its about the apps but I don''t know for sure. The problem did not happen before I updated to 0.80 of Baikal which I did on 05/31/2021.

Maybe we can find the cause together as I need to dig deeper into it because it currently happens again on customer side.

codiflow avatar Oct 09 '21 10:10 codiflow

Some more details on the problem:

An example for such an "defective" calendar entry which produces error 500 is as follows:

BEGIN:VCALENDAR
VERSION:2.0
PRODID:DAVx5/3.4.0.1-mgd ical4j/3.1.0 (com.appgenix.bizcal)
BEGIN:VEVENT
DTSTAMP:20211006T130807Z
UID:0841d0e5-4ad5-4006-8267-d2e995533238
SEQUENCE:2
SUMMARY:This is the summary
LOCATION:Some location
DTSTART;TZID=Europe/Berlin:20211004T123000
DTEND;TZID=Europe/Berlin:20211004T133000
RRULE:FREQ=WEEKLY;WKST=MO;UNTIL=20211007T102959Z;BYDAY=TU,TH,SA
EXDATE;TZID=Europe/Berlin:20211004T123000
CLASS:PUBLIC
STATUS:CONFIRMED
CATEGORIES:Come From :com.appgenix.bizcal
BEGIN:VALARM
TRIGGER:-PT15M
ACTION:DISPLAY
DESCRIPTION:This is the description
END:VALARM
END:VEVENT
BEGIN:VTIMEZONE
TZID:Europe/Berlin
LAST-MODIFIED:20201010T011803Z
BEGIN:DAYLIGHT
TZNAME:CEST
TZOFFSETFROM:+0100
TZOFFSETTO:+0200
DTSTART:19810329T020000
RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=-1SU
END:DAYLIGHT
BEGIN:STANDARD
TZNAME:CET
TZOFFSETFROM:+0200
TZOFFSETTO:+0100
DTSTART:19961027T030000
RRULE:FREQ=YEARLY;BYMONTH=10;BYDAY=-1SU
END:STANDARD
END:VTIMEZONE
END:VCALENDAR

I think the recurrence rule doesn't make any sense. The event takes place on Monday and the repetition already ends after three days on Thursday but should be repeated weekly on Tuesday, Thursday and Saturday. So the "Saturday" would never match and neither would the weekly. The calendar app which produces those entries is Business Calendar 2 (com.appgenix.bizcal)

EDIT: After some more research its more clear to me now. The "weekly" can't be the problem because its the only way to only repeat the event on different days of a week. So the main problem seems to be that the repetition already ends on Thursday but theres also a recurrence set for Saturday which would never match (and therefore produce no valid entry). I will dig deeper into this as this could also point out some "server side problem" with handling such events.

EDIT2: Now I digged deeper into it and got the issue:

The event date is set to Monday the 4th with a weekly recurrence rule for Tuesday, Thursday and Saturday. But Monday (which is the events date) is explicit excluded from this rule (first thing which is strange) and the recurrence rule ends before the event would be created on Thursday and Saturday (20211007T102959Z). So the only instance which got created by the recurrence rule is the event on Tuesday. Therefore the whole recurrence rule doesn't make any sense. It would be easier to just create the event on Tuesday without any recurrence rule.

I also simulated the same setting with an iOS device. But iOS handles recurrences differently and creates own events out of the set recurrence rule and references them between all instances. So this can't be compared to Androids behaviour and therefore it seems to be an Android only issue which originates totally on the user side.

codiflow avatar Oct 11 '21 19:10 codiflow

Ah and the software stack we use is:

Baikal 0.80 Managed DAVx5 3.4.0.1 Android 9 (and others)

codiflow avatar Oct 11 '21 19:10 codiflow

I have the same problem. Luckily I could identify the problem-events from the notification by davx5 (by opening the details in browser). I would be very lucky, if this bug would get fixed!

cyberbeat avatar Jun 10 '23 19:06 cyberbeat