Duplicate Google Calendars with @ and %40

[NicholasFlamy]

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 16 (LineageOS on Pixel 8a)

Steps to reproduce

1. Add Google Account a while back
2. Refresh calendar list today (August 16, 2026) on app version 4.5.19-ose.
3. Observe duplication.

Actual result

Duplicate calendars, one with @ symbol in URL and one with %40 in place of @ symbol in URL

Expected result

No duplicates, smarter handling of what is likely Google's incompetence.

Further info

No response

[cketti]

Does the URL start with https://apidata.googleusercontent.com? If not, it's probably best to remove the account and add it again.

[NicholasFlamy]

Does the URL start with https://apidata.googleusercontent.com? If not, it's probably best to remove the account and add it again.

Yes, it does. The full URL is https://apidata.googleusercontent.com/caldav/v2/<redacted-id>@virtual/events/ with the only difference between the two duplicates being that the @ before virtual is @ or %40.

[cketti]

I can reproduce the behavior when I manually change a collection URL in the database from using @ to %40. When refreshing the list, a collection with @ in the URL will be added (again), but the one using %40 isn't removed.

The reason seems to be that we only delete collections locally when querying the remote collection results in one of the HTTP status codes 403, 404, or 410. That's not happening in this case, because %40 is treated like @ on the server and non-error responses are returned.

To fix this, we should probably remove all local collections that can no longer be found on the server when refreshing the collection list.

[NicholasFlamy]

The reason seems to be that we only delete collections locally when querying the remote collection results in one of the HTTP status codes 403, 404, or 410. That's not happening in this case, because %40 is treated like @ on the server and non-error responses are returned.

That makes a lot of sense and is similar to what I imagined.

To fix this, we should probably remove all local collections that can no longer be found on the server when refreshing the collection list.

You might want to add handling to enable the replacement in case Google or whatever provider regularly changes what they return. I suspect they used to return it with %40 and now return it with @.

[rfc2822]

To fix this, we should probably remove all local collections that can no longer be found on the server when refreshing the collection list.

However not all servers support homeset iteration, and a collection URL in question may be the manually entered base URL (not necessarily included in the homesets). I'd be very careful when removing local collections (there's always a chance of unwanted side effects).

So if the DAVx5 account is removed and added again, only the @ version is shown? Maybe then that's the best workaround.