CalendarStorageException when infinite RRULE + RDATE present

[rfc2822]

Discussed in bitfireAT/davx5-ose#402

^{Originally posted by navid-zamani September 10, 2023}
Since there is no place to report bugs, I’m forced to post this here in a free format:

I get the above mentioned error when trying to sync.
I suspect it was caused by a bug in Lightning, but I switched to KOrganzizer as a result and it lets me edit and save the event just fine, which I did, to make sure the event on the Radicale server was valid. Lightning is fine with it now too (but I set it to read-only there, to avoid Lightning messing up some more).

I’ve added the debug info ZIP below, and also added the ICS file from the server to it.
davx5-debug.zip
Everything starting with “My…” is anonymized manually.

I am unable to find anything wrong with the ICS file, and since KOrganizer, Radicale, Thunderbird and an online validator handle it fine now, but DAVx⁵ (or more correctly, Android’s calendar provider or something) does not, all I can do it post it here and hope somebody more experienced can see what’s wrong.

It’s bad because I can’t use my calendar on my phone because of it right now. :/

[rfc2822]

Minimum iCalendar to reproduce the problem:

BEGIN:VCALENDAR
VERSION:2.0
CALSCALE:GREGORIAN
BEGIN:VEVENT
UID:9e2cd7fc-bf69-4035-a149-bec9aae8df15
DTSTART;VALUE=DATE:20230908
DTEND;VALUE=DATE:20230909
RDATE;VALUE=DATE:20230713
RRULE:FREQ=WEEKLY;BYDAY=TH
SUMMARY:Some Event
END:VEVENT
END:VCALENDAR

[rfc2822]

More adb details:

java.lang.IllegalArgumentException: Unable to compute LAST_DATE
	at com.android.providers.calendar.CalendarProvider2.handleUpdateEvents(CalendarProvider2.java:4107)
	at com.android.providers.calendar.CalendarProvider2.updateInTransactionInner(CalendarProvider2.java:4356)
	at com.android.providers.calendar.CalendarProvider2.updateInTransaction(CalendarProvider2.java:4208)
	at com.android.providers.calendar.SQLiteContentProvider.update(SQLiteContentProvider.java:168)
	at com.android.providers.calendar.CalendarProvider2.update(CalendarProvider2.java:2322)
	at android.content.ContentProvider.update(ContentProvider.java:2045)
	at android.content.ContentProviderOperation.applyInternal(ContentProviderOperation.java:391)
	at android.content.ContentProviderOperation.apply(ContentProviderOperation.java:352)
	at com.android.providers.calendar.SQLiteContentProvider.applyBatch(SQLiteContentProvider.java:236)
	at com.android.providers.calendar.CalendarProvider2.applyBatch(CalendarProvider2.java:2301)
	at android.content.ContentProvider.applyBatch(ContentProvider.java:2644)
	at android.content.ContentProvider$Transport.applyBatch(ContentProvider.java:514)
	at android.content.ContentProviderNative.onTransact(ContentProviderNative.java:212)
	at android.os.Binder.execTransactInternal(Binder.java:1339)
	at android.os.Binder.execTransact(Binder.java:1275)
Caused by: com.android.calendarcommon2.DateException: No range end provided for a recurrence that has no UNTIL or COUNT.
	at com.android.calendarcommon2.RecurrenceProcessor.expand(RecurrenceProcessor.java:766)
	at com.android.calendarcommon2.RecurrenceProcessor.expand(RecurrenceProcessor.java:661)
	at com.android.calendarcommon2.RecurrenceProcessor.getLastOccurence(RecurrenceProcessor.java:130)
	at com.android.calendarcommon2.RecurrenceProcessor.getLastOccurence(RecurrenceProcessor.java:61)
	at com.android.providers.calendar.CalendarProvider2.calculateLastDate(CalendarProvider2.java:3221)
	at com.android.providers.calendar.CalendarProvider2.handleUpdateEvents(CalendarProvider2.java:4105)
	... 14 more

[rfc2822]

Seems that I have already created an Android issue for this problem on Jan 26, 2022: CalendarProvider crashes with RDATE and infinite RRULE. It's "Assigned" but not fixed yet.

However, we should deal with the problem somehow so that people don't get exceptions and can synchronize their other events.

Maybe ignore the RDATEs when an infinite RRULE is present…

@navid-zamani How would you expect such events to be treated by DAVx⁵ when it's impossible to store them correctly in Android? Ignore the RDATEs? Ignore the whole event?

[navid-zamani]

@rfc2822: I think automagic treatment always leads to silent corruption. Which in any important setting leads to firings. E.g. when an appointment is missed.

What would such properties of an event mean, according to the format definition? Is it invalid? In that case the best solution would be to tell the user that the software he used to create the event elsewhere is broken, and he must edit the event there, to remove the invalid property. (E.g. remove the recurrence completely, add a recurrence back in, sync, and if it still fails, report the bug to the developers of that other software.) (It seems the name of that software can be pulled from the ICS? As well as the name and date/time of the event, of course, as an ID is not useful in a GUI.)

And if it is valid, the best thing to do is what the standard intended.

If the standard is vague, ambiguous or self-contradicting, it’s probably best to also treat it as a defect like above. (As you cannot change your side, due to Android’s treatment of the event being outside of your control.)

Data loss is the one thing that can never happen.

[navid-zamani]

Thank you for reporting this Android issue. :)

(Not that it would do me any good. I don’t get Android updates on my cheaper phone anymore I think.)