For weeks now I had a sync exception from my DAVx app, indicating a problem when syncing my CalDAV calendar from SOGo. As Thunderbird was not affected I managed to ignore the problem for quite some time. But then I noticed that some newer appointments are not synced anymore. So I had to investigate.

DAVx allows you to export debug information, where the error is shown as:

Account: Account {,}

at.bitfire.dav4jvm.exception.DavException: Received multi-get response without calendar data
at at.bitfire.davdroid.syncadapter.CalendarSyncManager$downloadRemote$1$1$onResponse$1.invoke(CalendarSyncManager.kt:9)
at at.bitfire.davdroid.syncadapter.CalendarSyncManager$downloadRemote$1$1$onResponse$1.invoke(CalendarSyncManager.kt:1)
at at.bitfire.davdroid.syncadapter.SyncManager.responseExceptionContext(SyncManager.kt:13)
at at.bitfire.davdroid.syncadapter.CalendarSyncManager$downloadRemote$1$1.onResponse(CalendarSyncManager.kt:18)
at at.bitfire.dav4jvm.Response$Companion.parse(Response.kt:308)

A few lines later the log file specifies the remote source as:


I tried to delete the calendar from my device and set it up again, but to no avail. After a bit of digging I got the impression that something was wrong with the calendar entry. Unfortunately the log file doesn’t say anything about the calendar entry other than the link. So I can’t look at the entry in Thunderbird or the SOGo web interface.
But I am running my own SOGO instance so I am able to check the SOGo database entry.

SOGo organizes data in a series of tables named sogo${username}${hash}. The c_name of every table corresponds with the event name from the URL. So we can look for the event and it’s content in the tables:

MariaDB [sogo]> select c_content from sogobenjamin0010de46299 where c_name like '%2930%';
| c_content |
| |
1 row in set (0.005 sec)

Apparently the event just has an empty c_content field which is what threw off DAVx. As I don’t know anything else about the event and there is nothing to restore, I just deleted the entry from the table:

MariaDB [sogo]> delete from sogobenjamin0010de46299 where c_name like '%2930%';
Query OK, 1 row affected (0.012 sec)

After that DAVx was able to sync again without issues.