Collision when uploading different events with same iCalUid

[h3xx]

Problem scope

• I'm sure that this is a DAVx⁵ problem.

App version

• I'm using the latest available DAVx⁵ version.

Android version and device/firmware type

Android 14 (Samsung A53)

Steps to reproduce

1. Import an event from an ICS file (e.g. via "Forward as iCalendar" from Outlook) on the Android device into the Google Calendar app
2. Initiate sync in Davx5. --> Event is created on the remote server. ✅
3. Delete event via Google Calendar.
4. Initiate sync again. --> Event is deleted from remote server. ✅
5. Re-open same ICS file via Google Calendar to import event.
6. Initiate sync in Davx5. --> Event is deleted locally and never created remotely. ❌

Actual result

Repeating steps 5-6, it appears that the event can never exist again, always being deleted by Davx5.

Expected result

Event should be re-created on the remote server, and should stay in the local calendar.

Further info

I'm using Davx5 to sync a CalDAV (radicale) calendar running on my personal server.

Seen in Davx5 version 4.4.2-ose (downloaded from F-Droid repo).

Logs (just from Step 6 above):

• davx5-log.txt
• debug-info.txt

[rfc2822]

The events all some to have UID:040000008200E00074C5B7101A82E00800000000104BFAA052B7DA010000000000000000100000001A4B7DAE03C4644AA6D003013647EF80, so DAVx5 will always use 040000008200E00074C5B7101A82E00800000000104BFAA052B7DA010000000000000000100000001A4B7DAE03C4644AA6D003013647EF80.ics as file name and then there are collisions.

Why do all these events have iCalUid = 040000008200E00074C5B7101A82E00800000000104BFAA052B7DA010000000000000000100000001A4B7DAE03C4644AA6D003013647EF80 in the database?

Can you provide exact steps to reproduce this, including a sample iCalendar (ics file) that we can use?

Why are you sure that this is a DAVx5 problem and Google Calendar isn't inserting malicious things into the database (indeed the iCalUid seems questionable)?

I remember that at some time we decided to use the proprietary iCalUid as UID to support some other use case (#511). Seems that this is causing problems now …