Fail after editing a recurring event (Overwritten recurrence with RRULESET)

[Massedil]

Hello,

I have a sync problem with one event.

I have used Etar to update a recurring event and change one specific day title from "Escalade" to "Escalade avec Romain".

On the server, the event before change is :

BEGIN:VCALENDAR
VERSION:2.0
PRODID:DAVx5/4.4.0.1-ose ical4j/3.2.18
BEGIN:VTIMEZONE
TZID:Europe/Paris
BEGIN:STANDARD
DTSTART:19961027T030000
RRULE:FREQ=YEARLY;BYMONTH=10;BYDAY=-1SU
TZNAME:CET
TZOFFSETFROM:+0200
TZOFFSETTO:+0100
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:19810329T020000
RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=-1SU
TZNAME:CEST
TZOFFSETFROM:+0100
TZOFFSETTO:+0200
END:DAYLIGHT
END:VTIMEZONE
BEGIN:VEVENT
UID:9fb6578a-07a6-4c61-8406-69229713d40e
DTSTART;TZID=Europe/Paris:20240606T193000
DTEND;TZID=Europe/Paris:20240606T203000
CLASS:PUBLIC
DTSTAMP:20240622T134646Z
EXDATE;TZID=Europe/Paris:20240704T193000
RRULE:FREQ=WEEKLY;WKST=MO;BYDAY=TH
SEQUENCE:2
STATUS:CONFIRMED
SUMMARY:Escalade
BEGIN:VALARM
ACTION:DISPLAY
DESCRIPTION:Escalade
TRIGGER:-P1D
END:VALARM
END:VEVENT
END:VCALENDAR

The changes sent by DAVx5 (tabs are added by me for readability) :

BEGIN:VCALENDAR
	VERSION:2.0
	PRODID:DAVx5/4.4.3.2-ose ical4j/3.2.19
	BEGIN:VEVENT
		DTSTAMP:20241125T195941Z
		UID:9fb6578a-07a6-4c61-8406-69229713d40e
		SEQUENCE:3
		SUMMARY:Escalade
		DTSTART;TZID=Europe/Paris:20240606T193000
		DTEND;TZID=Europe/Paris:20240606T203000
		RRULE:FREQ=WEEKLY;WKST=MO;BYDAY=TH
		EXDATE;TZID=Europe/Paris:20240704T193000
		CLASS:PUBLIC
		STATUS:CONFIRMED
		BEGIN:VALARM
			TRIGGER:-P1D
			ACTION:DISPLAY
			DESCRIPTION:Escalade
		END:VALARM
	END:VEVENT
	BEGIN:VEVENT
		DTSTAMP:20241125T195941Z
		UID:9fb6578a-07a6-4c61-8406-69229713d40e
		RECURRENCE-ID;TZID=Europe/Paris:20241128T193000
		SEQUENCE:1
		SUMMARY:Escalade avec Romain
		DTSTART;TZID=Europe/Paris:20241128T193000
		DTEND;TZID=Europe/Paris:20241128T203000
		EXDATE;TZID=Europe/Paris:20240704T193000
		CLASS:PUBLIC
		STATUS:CONFIRMED
		BEGIN:VALARM
			TRIGGER:-P1D
			ACTION:DISPLAY
			DESCRIPTION:Escalade avec Romain
		END:VALARM
	END:VEVENT
	BEGIN:VTIMEZONE
		TZID:Europe/Paris
		BEGIN:STANDARD
			TZNAME:CET
			TZOFFSETFROM:+0200
			TZOFFSETTO:+0100
			DTSTART:19961027T030000
			RRULE:FREQ=YEARLY;BYMONTH=10;BYDAY=-1SU
		END:STANDARD
		BEGIN:DAYLIGHT
			TZNAME:CEST
			TZOFFSETFROM:+0100
			TZOFFSETTO:+0200
			DTSTART:19810329T020000
			RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=-1SU
		END:DAYLIGHT
	END:VTIMEZONE
END:VCALENDAR

Radicale answer with a 400 Bad Request HTTP reply.

In Radicale's logs, I found :

[WARNING] Bad PUT request on 'XXXXXXXXXX.ics': Overwritten recurrence with RRULESET

• What is the problem ?
• Who is responsible of the problem ? Etar, Radicale or DAVx5 ?
• Can DAVx5 handle this problem ? (Even if not responsible)

Versions :

• Radicale : 3.0.6
• DAVx5 : 4.4.3.2-ose
• Etar : 1.0.48

---

I also sent this report here :
Kozea/Radicale#1635

---

I have done a search for similar discussions and found this :

• 400 Bad Request: Overwritten recurrence with RRULESET davx5-ose#66

It is said :

In short: SimpleCalendar has a special way of handling exceptions. DAVx5 however treats the Android calendar provider the standard way which most other calendar apps do too.

You may consider using another CalendarApp.

I here use Etar, and I'm not sure the problem is the same, maybe only the Etar answer seems the same.

[rfc2822]

I have used Etar to update a recurring event and change one specific day title from "Escalade" to "Escalade avec Romain".

Where is there original event from?

The exception contains an EXDATE and it looks like Radicale then rejects the event. It's not very clear whether this is allowed or not – some software (like Apple) sometimes to it, others don't. However, Radicale shouldn't reject it.

DAVx5 normally has the policy to not include recurrence information in the exceptions and removes possible RRULEs from exceptions (see #138). However it doesn't remove RDATE and EXDATE yet, which we should do.

So to summarize, this is an unclear situation (because the iCalendard can be interpreted in multiple ways). To maximize compatibility, in my opinion:

• Radicale should accept events with exceptions that contain RDATE, RRULE, EXDATE (and just drop it if needed)
• DAVx5 shouldn't generate events with exceptions that contain RDATE (already one), RRULE, EXDATE (to be done)

[Massedil]

Thanks for your detailed reply !

Where is there original event from?

Likely from Etar, may be created on an older version.

What is still unclear to me is if the event VCALENDAR format is created by DAVx5 or by Etar. If I try to share this event with the Etar "Share" function in the app, the shared event is not the event VCALENDAR DAVx5 is sending. But maybe it is normal !

My actual devices :

• Phone 1 : event updated that can't be synced
• Phone 2 : event without the update because it is not synced
• Radicale server : event without the update because it is refused

I got this from the event on phone 2 by using Etar share option, so it is the original event before trying to update :

BEGIN:VCALENDAR
VERSION:2.0
CALSCALE:GREGORIAN
METHOD:REQUEST
PRODID:-//Etar//ws.xsoh.etar
BEGIN:VEVENT
UID:[email protected]
DTSTAMP:20241129T151856Z
SUMMARY:Escalade
DTSTART:20241107T183000Z
DTEND:20241107T193000Z
ORGANIZER;CN=XXXX@YYYY:mailto:XXXX@YYYY
END:VEVENT
END:VCALENDAR

We can see PRODID is different so the event VCALENDAR is generated by DAVx5 ?

So to summarize, this is an unclear situation (because the iCalendard can be interpreted in multiple ways). To maximize compatibility, in my opinion:

• Radicale should accept events with exceptions that contain RDATE, RRULE, EXDATE (and just drop it if needed)
• DAVx5 shouldn't generate events with exceptions that contain RDATE (already one), RRULE, EXDATE (to be done)

Thanks you : it's clear !

• So I deduce the event is generated by Etar ? Or is it in an Android store between Etar and DAVx5 ?

• Do I need to open an issue in Etar ?

[rfc2822]

• So I deduce the event is generated by Etar ? Or is it in an Android store between Etar and DAVx5 ?

It's generate by Etar and stored as database fields in the Android store. DAVx5 reads the Android store, generates the iCalendar and sends it to the server. When doing so, we can apply additional fixes, but the calendar app should also generate only valid data. There's an image at https://www.davx5.com/faq/system-integration that shows the integration.

However there is some processing like that cancelled events are converted to an EXDATE by DAVx5, maybe that was the cause.

I'd need all steps including how to generate the exception, and with which app etc. to say what really happens.

[rfc2822]

However on DAVx5 side this should be done with #191

[Massedil]

However there is some processing like that cancelled events are converted to an EXDATE by DAVx5, maybe that was the cause.

Can I do something for you to show the state of the Android store database ? Is it a sqlite file I can access with root ?

However on DAVx5 side this should be done with #191

Thank you for your reactivity.

[rfc2822]

Can I do something for you to show the state of the Android store database ? Is it a sqlite file I can access with root ?

Either that (it's in the data directory of the calendar provider system package), or you can use adb shell content as shown in the FAQ: how to debug.

[Massedil]

With adb shell content query --uri content://com.android.calendar/events :

originalAllDay=NULL
account_type=bitfire.at.davdroid
exrule=NULL
mutators=NULL
originalInstanceTime=NULL
allDay=0
allowedReminders=0,1,2
rrule=FREQ=WEEKLY;WKST=MO;BYDAY=TH
canOrganizerRespond=1
lastDate=NULL
visible=1
calendar_id=1
hasExtendedProperties=0
calendar_access_level=700
selfAttendeeStatus=0
allowedAvailability=0,1
eventColor_index=NULL
isOrganizer=1
_sync_id=9fb6578a-07a6-4c61-8406-69229713d40e.ics
calendar_color_index=NULL
_id=1206
guestsCanInviteOthers=1
allowedAttendeeTypes=0,2,1,3
dtstart=1717695000000
guestsCanSeeGuests=1
sync_data9=NULL
sync_data8=NULL
exdate=Europe/Paris;20240704T193000
sync_data7=NULL
sync_data6=NULL
sync_data1=[REMOVED]
description=NULL
eventTimezone=Europe/Paris
availability=0
title=Escalade
ownerAccount=[REMOVED]
sync_data5=NULL
sync_data4=NULL
sync_data3=2
sync_data2=1
duration=PT1H
lastSynced=0
guestsCanModify=0
cal_sync3=NULL
rdate=NULL
cal_sync2=NULL
maxReminders=5
isPrimary=1
cal_sync1={"type":"SYNC_TOKEN","value":"http:\/\/radicale.org\/ns\/sync\/[REMOVED]","initialSync":false}
cal_sync10=NULL
account_name=[REMOVED]
cal_sync7=NULL
cal_sync6=NULL
cal_sync5=NULL
cal_sync4=NULL
calendar_color=-5317
cal_sync9=NULL
cal_sync8=NULL
dirty=1
calendar_timezone=NULL
accessLevel=3
eventLocation=NULL
hasAlarm=1
uid2445=9fb6578a-07a6-4c61-8406-69229713d40e
deleted=0
eventColor=NULL
organizer=[REMOVED]
eventStatus=1
customAppUri=NULL
canModifyTimeZone=1
eventEndTimezone=NULL
customAppPackage=NULL
original_sync_id=NULL
hasAttendeeData=0
displayColor=-5317
dtend=NULL
original_id=NULL
sync_data10=NULL
calendar_displayName=[REMOVED]

@rfc2822 Is it helpful ? Can I help you more ?

[rfc2822]

There's no EXDATE nor a cancelled exception…

However I think it's already done, so no more information necessary.

[Massedil]

Thanks for your reactivity !

So the problem is (was) from DAVx5 and will be solved with next version ?

[rfc2822]

I'm not able to reproduce the problem with Etar and DAVx5 only. So I don't know how the exception with RRULE came into the database. DAVx5 normally doesn't insert it.

So: I can't say where your problem originated. I only know such behavior from Simple Calendar and imported Apple events.

However DAVx5 now has an additional layer to filter such entries which are not strictly invalid but "strange enough" that some servers seem to reject them.

[Massedil]

So I don't know how the exception with RRULE came into the database.

But can't we see that there is no RRULE for the exception in the Android Store database (rrule=NULL) ?

[rfc2822]

Yes, and also the problem is not reproducible, at least not here.

[Massedil]

Thanks again for all your time trying to solve this problem.

It is sure I don't understand everything here, but for what I understand, the event in the Android Store database is normal. So with my version on phone 1, DAVx5 create a wrong VCALENDAR object.

Again, if I well unserstand, thanks to your correction, DAVx5 will clean his own VCALENDAR to remove stranged things it seems to have generated.

Yes, and also the problem is not reproducible, at least not here.

The problem is still reproductible on my phone 1.

So, if you want me to help you test a debug apk to find where the problem is generated, don't hesitate to ask me. If you think cleaning is sufficient, I'll will simply do the update when published in F-Droid.

Thanks ! :)

[rfc2822]

It is sure I don't understand everything here, but for what I understand, the event in the Android Store database is normal. So with my version on phone 1, DAVx5 create a wrong VCALENDAR object.

No, I can't imagine that. DAVx5 shouldn't add RRULEs / EXDATEs to exceptions, and it does not according to my tests.

But if you can provide steps that allow to reproduce the problem here, I will have a look again.

Again, if I well unserstand, thanks to your correction, DAVx5 will clean his own VCALENDAR to remove stranged things it seems to have generated.

DAVx5 maps the Android calendar provider RRULE to the iCalendar RRULE and doesn't add RRULEs on its own. There are some fixes for invalid values from the calendar provider, but they don't generate RRULEs on their own, too.

So I'd really be happy about steps to reproduce.

Otherwise I still think that the original event in the data store must have some problem…

The problem is still reproductible on my phone 1.

Can you please

• enable verbose logging in DAVx5 on this device
• sync, which should generate the error notification,
• export the debug info with still enabled verbose logs and send them to https://www.davx5.com/support with reference to this discussion,
• disable verbose logging again.

Then I can have a look again.

[pbiering]

Radicale >= 3.3.2 ignores now RRULESET in case empty.

See also

• Fail after editing a recurring event (Overwritten recurrence with RRULESET) Kozea/Radicale#1635
• ignore RRULESET if empty in item Kozea/Radicale#1643

Issue was triggered by a "sub" component containing EXDATE but nothing else (taken over from "main" component somehow by a bug?). vobject does not further validate this but create a ruleset object (even with no rule inside). Radicale has a failsafe mechanism inside to avoid infinite loops and triggered an exception even if no ruleset is existing. This was now improved by ignore the vobject ruleset object if having length of 0.

[pbiering]

The sequence which lead to the issue is imho the following

1. create daily schedule with repeat span of 5 days
2. delete single occurence on the 3rd day
3. rename single occurence on the 2nd day

on step 3 the buggy client copies the EXDATE attribute from the daily schedule with related exclude of step 2 into the single renamed occurrence

[rfc2822]

Not reproducible here with these steps with latest Etar and DAVx5 (even with the DAVx5 without the remove-exdate-workaround).

[pbiering]

I was also not able to reproduce, from the ticket #189 it must be somehow happened with

• create with PRODID:DAVx5/4.4.0.1-ose ical4j/3.2.18
• modify with PRODID:DAVx5/4.4.3.2-ose ical4j/3.2.19

[rfc2822]

But we don't know whether the questionable event was inserted into the Android store and DAVx5 just created the iCalendar from it (how I suspect it) or whether DAVx5 created the additional EXDATE (which is theoretically possible, but I don't know when/how this should have happened).

So without being able to reproduce it, I can just offer the filter which is already applied. Together with the server-side filter we should be on the safe side.

And after all, the questionable iCalendar is not strictly invalid, only "strange". And even systems like Apple generate such things…

[Massedil]

Can you please

• enable verbose logging in DAVx5 on this device
• sync, which should generate the error notification,
• export the debug info with still enabled verbose logs and send them to https://www.davx5.com/support with reference to this discussion,
• disable verbose logging again.

Then I can have a look again.

Hello,

Sorry for the delay, I was without a computer and it is easier to have one to anonymize the log file.

Here is what I have found useful in the log :

2024-12-06 17:29:05 55 [.AndroidEvent]               Read event entity from calender provider
	PARAMETER #1 = organizer=[REMOVED_EMAIL_1] duration=PT1H sync_data1=b48830afbce293a59916ab884bfdca62b34906fcb98be956f859e25995cb24c4 sync_data2=1 sync_data3=2 guestsCanModify=0 guestsCanSeeGuests=1 allDay=0 cal_sync1={"type":"SYNC_TOKEN","value":"http:\/\/radicale.org\/ns\/sync\/42d9ff79897170b8e2ccebb2bd5f3905866d57116146cfa36214795a8816f371","initialSync":false} exdate=Europe/Paris;20240704T193000 accessLevel=3 isOrganizer=1 hasAttendeeData=0 uid2445=9fb6578a-07a6-4c61-8406-69229713d40e guestsCanInviteOthers=1 _id=1206 dirty=1 eventStatus=1 rrule=FREQ=WEEKLY;WKST=MO;BYDAY=TH title=Escalade hasAlarm=1 selfAttendeeStatus=0 eventTimezone=Europe/Paris calendar_id=1 _sync_id=9fb6578a-07a6-4c61-8406-69229713d40e.ics deleted=0 hasExtendedProperties=0 lastSynced=0 dtstart=1717695000000 availability=0
2024-12-06 17:29:05 55 [.AndroidEvent]               Read event reminder from calender provider
	PARAMETER #1 = method=1 minutes=1440
2024-12-06 17:29:05 55 [.AndroidEvent]               Read event entity from calender provider
	PARAMETER #1 = organizer=[REMOVED_EMAIL_1] sync_data3=1 guestsCanModify=0 guestsCanSeeGuests=1 lastDate=1732822200000 allDay=0 cal_sync1={"type":"SYNC_TOKEN","value":"http:\/\/radicale.org\/ns\/sync\/42d9ff79897170b8e2ccebb2bd5f3905866d57116146cfa36214795a8816f371","initialSync":false} exdate=Europe/Paris;20240704T193000 accessLevel=3 isOrganizer=1 original_sync_id=9fb6578a-07a6-4c61-8406-69229713d40e.ics hasAttendeeData=0 guestsCanInviteOthers=1 _id=3141 dirty=0 dtend=1732822200000 eventStatus=1 title=Escalade avec Romain hasAlarm=1 selfAttendeeStatus=0 eventTimezone=Europe/Paris calendar_id=1 originalAllDay=0 originalInstanceTime=1732818600000 deleted=0 hasExtendedProperties=0 original_id=1206 lastSynced=0 dtstart=1732818600000 availability=0


[...]

2024-12-06 17:29:06 55 [.sync.CalendarSyncManager]   Preparing upload of event 9fb6578a-07a6-4c61-8406-69229713d40e.ics
	PARAMETER #1 = Event(uid=9fb6578a-07a6-4c61-8406-69229713d40e, sequence=3, userAgents=[], recurrenceId=null, summary=Escalade, location=null, url=null, description=null, color=null, dtStart=DTSTART;TZID=Europe/Paris:20240606T193000
, dtEnd=DTEND;TZID=Europe/Paris:20240606T203000
, duration=null, rRules=[RRULE:FREQ=WEEKLY;WKST=MO;BYDAY=TH
], exRules=[], rDates=[], exDates=[EXDATE;TZID=Europe/Paris:20240704T193000
], exceptions=[Event(uid=null, sequence=1, userAgents=[], recurrenceId=RECURRENCE-ID;TZID=Europe/Paris:20241128T193000
, summary=Escalade avec Romain, location=null, url=null, description=null, color=null, dtStart=DTSTART;TZID=Europe/Paris:20241128T193000
, dtEnd=DTEND;TZID=Europe/Paris:20241128T203000
, duration=null, rRules=[], exRules=[], rDates=[], exDates=[EXDATE;TZID=Europe/Paris:20240704T193000
], exceptions=[], classification=CLASS:PUBLIC
, status=STATUS:CONFIRMED
, opaque=true, organizer=null, attendees=[], alarms=[BEGIN:VALARM
TRIGGER:-P1D
ACTION:DISPLAY
DESCRIPTION:Escalade avec Romain
END:VALARM
], lastModified=null, categories=[], unknownProperties=[])], classification=CLASS:PUBLIC
, status=STATUS:CONFIRMED
, opaque=true, organizer=null, attendees=[], alarms=[BEGIN:VALARM
TRIGGER:-P1D
ACTION:DISPLAY
DESCRIPTION:Escalade
END:VALARM
], lastModified=null, categories=[], unknownProperties=[])
2024-12-06 17:29:06 55 [.network.HttpClient]         --> PUT [REMOVED_URL_1]/c849028a-6e8f-4de7-b44a-8ace4d5a7efb/9fb6578a-07a6-4c61-8406-69229713d40e.ics http/1.1
2024-12-06 17:29:06 55 [.network.HttpClient]         If-Match: "b48830afbce293a59916ab884bfdca62b34906fcb98be956f859e25995cb24c4"
2024-12-06 17:29:06 55 [.network.HttpClient]         User-Agent: DAVx5/4.4.3.2-ose (dav4jvm; okhttp/4.12.0) Android/12
2024-12-06 17:29:06 55 [.network.HttpClient]         Accept-Language: fr-FR, fr;q=0.7, *;q=0.5
2024-12-06 17:29:06 55 [.network.HttpClient]         Content-Type: text/calendar;charset=utf-8
2024-12-06 17:29:06 55 [.network.HttpClient]         Content-Length: 1257
2024-12-06 17:29:06 55 [.network.HttpClient]         Host: cal.msd.im
2024-12-06 17:29:06 55 [.network.HttpClient]         Connection: Keep-Alive
2024-12-06 17:29:06 55 [.network.HttpClient]         Accept-Encoding: gzip
2024-12-06 17:29:06 55 [.network.HttpClient]         
2024-12-06 17:29:06 55 [.network.HttpClient]         BEGIN:VCALENDAR
VERSION:2.0
PRODID:DAVx5/4.4.3.2-ose ical4j/3.2.19
BEGIN:VEVENT
DTSTAMP:20241206T162906Z
UID:9fb6578a-07a6-4c61-8406-69229713d40e
SEQUENCE:3
SUMMARY:Escalade
DTSTART;TZID=Europe/Paris:20240606T193000
DTEND;TZID=Europe/Paris:20240606T203000
RRULE:FREQ=WEEKLY;WKST=MO;BYDAY=TH
EXDATE;TZID=Europe/Paris:20240704T193000
CLASS:PUBLIC
STATUS:CONFIRMED
BEGIN:VALARM
TRIGGER:-P1D
ACTION:DISPLAY
DESCRIPTION:Escalade
END:VALARM
END:VEVENT
BEGIN:VEVENT
DTSTAMP:20241206T162906Z
UID:9fb6578a-07a6-4c61-8406-69229713d40e
RECURRENCE-ID;TZID=Europe/Paris:20241128T193000
SEQUENCE:1
SUMMARY:Escalade avec Romain
DTSTART;TZID=Europe/Paris:20241128T193000
DTEND;TZID=Europe/Paris:20241128T203000
EXDATE;TZID=Europe/Paris:20240704T193000
CLASS:PUBLIC
STATUS:CONFIRMED
BEGIN:VALARM
TRIGGER:-P1D
ACTION:DISPLAY
DESCRIPTION:Escalade avec Romain
END:VALARM
END:VEVENT
BEGIN:VTIMEZONE
TZID:Europe/Paris
BEGIN:STANDARD
TZNAME:CET
TZOFFSETFROM:+0200
TZOFFSETTO:+0100
DTSTART:19961027T030000
RRULE:FREQ=YEARLY;BYMONTH=10;BYDAY=-1SU
END:STANDARD
BEGIN:DAYLIGHT
TZNAME:CEST
TZOFFSETFROM:+0100
TZOFFSETTO:+0200
DTSTART:19810329T020000
RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=-1SU
END:DAYLIGHT
END:VTIMEZONE
END:VCALENDAR

2024-12-06 17:29:06 55 [.network.HttpClient]         --> END PUT (1257-byte body)
2024-12-06 17:29:06 55 Adding Basic authorization header for [REMOVED_URL_1]/c849028a-6e8f-4de7-b44a-8ace4d5a7efb/9fb6578a-07a6-4c61-8406-69229713d40e.ics
2024-12-06 17:29:07 55 [.network.HttpClient]         <-- 400 Bad Request [REMOVED_URL_1]/c849028a-6e8f-4de7-b44a-8ace4d5a7efb/9fb6578a-07a6-4c61-8406-69229713d40e.ics (412ms)
2024-12-06 17:29:07 55 [.network.HttpClient]         Date: Fri, 06 Dec 2024 16:29:07 GMT
2024-12-06 17:29:07 55 [.network.HttpClient]         Server: Apache
2024-12-06 17:29:07 55 [.network.HttpClient]         Content-Type: text/plain; charset=utf-8
2024-12-06 17:29:07 55 [.network.HttpClient]         Content-Encoding: gzip
2024-12-06 17:29:07 55 [.network.HttpClient]         Content-Length: 31
2024-12-06 17:29:07 55 [.network.HttpClient]         Strict-Transport-Security: max-age=86400
2024-12-06 17:29:07 55 [.network.HttpClient]         Connection: close
2024-12-06 17:29:07 55 [.network.HttpClient]         
2024-12-06 17:29:07 55 [.network.HttpClient]         Bad Request
2024-12-06 17:29:07 55 [.network.HttpClient]         <-- END HTTP (11-byte, 31-gzipped-byte body)
2024-12-06 17:29:07 55 [.sync.SyncManager]           HTTP/DAV exception
	EXCEPTION at.bitfire.dav4jvm.exception.HttpException: HTTP 400 Bad Request
		at at.bitfire.dav4jvm.DavResource.checkStatus(DavResource.kt:3)
		at at.bitfire.dav4jvm.DavResource.checkStatus(DavResource.kt:1)
		at at.bitfire.dav4jvm.DavResource.put(DavResource.kt:26)
		at at.bitfire.dav4jvm.DavResource.put$default(DavResource.kt:27)
		at at.bitfire.davdroid.sync.SyncManager.uploadDirty$lambda$9(SyncManager.kt:83)
		at at.bitfire.davdroid.sync.SyncManager.$r8$lambda$ciPepfyyDYikAkEYLnqqEjkNrVQ(SyncManager.kt:1)
		at at.bitfire.davdroid.sync.SyncManager$$ExternalSyntheticLambda8.invoke(R8$$SyntheticClass:11)
		at at.bitfire.davdroid.sync.SyncException$Companion.wrapWithRemoteResource(SyncException.kt:6)
		at at.bitfire.davdroid.sync.SyncManager.uploadDirty(SyncManager.kt:18)
		at at.bitfire.davdroid.sync.SyncManager$uploadDirty$1$1.invokeSuspend$lambda$0(SyncManager.kt:1)
		at at.bitfire.davdroid.sync.SyncManager$uploadDirty$1$1.$r8$lambda$EhUcAl3Cb0hjXD1dbGbGBTnEoQc(SyncManager.kt:1)
		at at.bitfire.davdroid.sync.SyncManager$uploadDirty$1$1$$ExternalSyntheticLambda0.invoke(R8$$SyntheticClass:7)
		at at.bitfire.davdroid.sync.SyncException$Companion.wrapWithLocalResource(SyncException.kt:6)
		at at.bitfire.davdroid.sync.SyncManager$uploadDirty$1$1.invokeSuspend(SyncManager.kt:23)
		at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(ContinuationImpl.kt:9)
		at kotlinx.coroutines.DispatchedTask.run(DispatchedTask.kt:107)
		at kotlinx.coroutines.EventLoopImplBase.processNextEvent(EventLoop.common.kt:76)
		at kotlinx.coroutines.BuildersKt.runBlocking(Unknown Source:105)
		at kotlinx.coroutines.BuildersKt.runBlocking$default(Unknown Source:3)
		at at.bitfire.davdroid.sync.SyncManager.uploadDirty(SyncManager.kt:2)
		at at.bitfire.davdroid.sync.CalendarSyncManager.uploadDirty(CalendarSyncManager.kt:74)
		at at.bitfire.davdroid.sync.SyncManager.performSync(SyncManager.kt:90)
		at at.bitfire.davdroid.sync.CalendarSyncer.syncCollection(CalendarSyncer.kt:11)
		at at.bitfire.davdroid.sync.CalendarSyncer.syncCollection(CalendarSyncer.kt:1)
		at at.bitfire.davdroid.sync.Syncer.syncCollectionContents$davx5_ose_4_4_3_2_oseRelease(Syncer.kt:59)
		at at.bitfire.davdroid.sync.Syncer.sync$davx5_ose_4_4_3_2_oseRelease(Syncer.kt:36)
		at at.bitfire.davdroid.sync.Syncer.invoke(Syncer.kt:147)
		at at.bitfire.davdroid.sync.worker.BaseSyncWorker$doSyncWork$2.invokeSuspend$lambda$0(BaseSyncWorker.kt:1)
		at at.bitfire.davdroid.sync.worker.BaseSyncWorker$doSyncWork$2.$r8$lambda$MnrEU1_WtQZTTPjmMRztfG3Y7fo(BaseSyncWorker.kt:1)
		at at.bitfire.davdroid.sync.worker.BaseSyncWorker$doSyncWork$2$$ExternalSyntheticLambda0.invoke(R8$$SyntheticClass:3)
		at kotlinx.coroutines.InterruptibleKt$runInterruptible$2.invokeSuspend(Interruptible.kt:58)
		at kotlinx.coroutines.InterruptibleKt$runInterruptible$2.invoke(Interruptible.kt:13)
		at kotlinx.coroutines.intrinsics.UndispatchedKt.startUndispatchedOrReturn(Undispatched.kt:5)
		at kotlinx.coroutines.BuildersKt.withContext(Unknown Source:44)
		at kotlinx.coroutines.InterruptibleKt.runInterruptible$default(Interruptible.kt:9)
		at at.bitfire.davdroid.sync.worker.BaseSyncWorker$doSyncWork$2.invokeSuspend(BaseSyncWorker.kt:325)
		at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(ContinuationImpl.kt:9)
		at kotlinx.coroutines.DispatchedTask.run(DispatchedTask.kt:107)
		at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1167)
		at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:641)
		at java.lang.Thread.run(Thread.java:920)

I'm not sure about my interpretation, but can't we see that there is no rrule for title=Escalade avec Romain in the "calender provider" and that DAVx5 seems to add it to the BEGIN:VCALENDAR file ?

I will send you the full document davx5-log.txt via https://www.davx5.com/support.

[rfc2822]

I'm not sure about my interpretation, but can't we see that there is no rrule for title=Escalade avec Romain in the "calender provider" and that DAVx5 seems to add it to the BEGIN:VCALENDAR file ?

The "problem" is that in the exception there's an EXDATE (but no RRULE). "Problem" because it's not excplicity forbidden by the standard, but unusual and seemed to cause problems with your Radicale.

You can see the content provider entries that DAVx5 reads in the logs (relevant things bold):

Main event:

PARAMETER #1 = organizer=[REMOVED_EMAIL_1] duration=PT1H sync_data1=b48830afbce293a59916ab884bfdca62b34906fcb98be956f859e25995cb24c4 sync_data2=1 sync_data3=2 guestsCanModify=0 guestsCanSeeGuests=1 allDay=0 cal_sync1={"type":"SYNC_TOKEN","value":"http://radicale.org/ns/sync/42d9ff79897170b8e2ccebb2bd5f3905866d57116146cfa36214795a8816f371","initialSync":false} exdate=Europe/Paris;20240704T193000 accessLevel=3 isOrganizer=1 hasAttendeeData=0 uid2445=9fb6578a-07a6-4c61-8406-69229713d40e guestsCanInviteOthers=1 _id=1206 dirty=1 eventStatus=1 rrule=FREQ=WEEKLY;WKST=MO;BYDAY=TH title=Escalade hasAlarm=1 selfAttendeeStatus=0 eventTimezone=Europe/Paris calendar_id=1 _sync_id=9fb6578a-07a6-4c61-8406-69229713d40e.ics deleted=0 hasExtendedProperties=0 lastSynced=0 dtstart=1717695000000 availability=0

Recurring event, RRULE set, EXDATE set, all fine.

Exception:

PARAMETER #1 = organizer=[REMOVED_EMAIL_1] sync_data3=1 guestsCanModify=0 guestsCanSeeGuests=1 lastDate=1732822200000 allDay=0 cal_sync1={"type":"SYNC_TOKEN","value":"http://radicale.org/ns/sync/42d9ff79897170b8e2ccebb2bd5f3905866d57116146cfa36214795a8816f371","initialSync":false} exdate=Europe/Paris;20240704T193000 accessLevel=3 isOrganizer=1 original_sync_id=9fb6578a-07a6-4c61-8406-69229713d40e.ics hasAttendeeData=0 guestsCanInviteOthers=1 _id=3141 dirty=0 dtend=1732822200000 eventStatus=1 title=Escalade avec Romain hasAlarm=1 selfAttendeeStatus=0 eventTimezone=Europe/Paris calendar_id=1 originalAllDay=0 originalInstanceTime=1732818600000 deleted=0 hasExtendedProperties=0 original_id=1206 lastSynced=0 dtstart=1732818600000 availability=0 [no rrule, so rrule=null]

This exception (the VEVENT with the RECURRENCE-ID) has an EXDATE, but no RRULE.

This is exactly what DAVx5 sent to the server, and the server rejected the event.

[Massedil]

Thanks, I understood !