timezone expansion goes wrong for Morgen's Bookingpage

[bbbart]

I am using Morgen (https://morgen.so) as a calendar app with some Baïkal and and some Google calendars in the backend, but their booking page feature wasn't working well with their caldav integration and Baïkal (with my Google calendar all was fine).

We recently migrated from Radicale to Baïkal, which is when the issues started.

Everything seems t work fine at first glance: calendars show up, entries are added, synchronisation works just fine. However, booking pages created and hosted by Morgen never show Baïkal caldav entries as unavailable. After some log checking, I saw that every time the booking page was opened, a request for availability was sent to Baïkal, which returned an error:

PHP message: SabreVObjectParseException: This parser only supports VCARD and VCALENDAR files in /opt/baikal/vendor/sabre/vobject/lib/Parser/MimeDir.php:163

Some more searching pointed me to https://github.com/sabre-io/Baikal/issues/1085#issuecomment-1418295860 which at first glance also seems to solve this issue.

As per https://github.com/sabre-io/Baikal/issues/1085, https://github.com/sabre-io/dav/issues/1318 and this problem, it seems that integrations with Asterisk, HomeAssistant and Morgen are all failing at the same point in the code. Perhaps this warrants a patch, or am I missing something?

[DeepDiver1975]

PHP message: SabreVObjectParseException: This parser only supports VCARD and VCALENDAR files in /opt/baikal/vendor/sabre/vobject/lib/Parser/MimeDir.php:163

can you share the request especially the request body so that we can see what is coming across from the client. THX

[bbbart]

sure. here's the request body:

"<?xml version=\x221.0\x22 encoding=\x22utf-8\x22 ?>\x0A<C:calendar-query xmlns:D=\x22DAV:\x22 xmlns:C=\x22urn:ietf:params:xml:ns:caldav\x22>\x0A  <D:prop>\x0A    <C:calendar-data>\x0A      <C:expand start=\x2220240118T000000Z\x22 end=\x2220240508T000000Z\x22/>\x0A    </C:calendar-data>\x0A  </D:prop>\x0A  <C:filter>\x0A    <C:comp-filter name=\x22VCALENDAR\x22>\x0A      <C:comp-filter name=\x22VEVENT\x22>\x0A        <C:time-range start=\x2220240118T000000Z\x22 end=\x2220240508T000000Z\x22/>\x0A      </C:comp-filter>\x0A    </C:comp-filter>\x0A  </C:filter>\x0A</C:calendar-query>"

and the request headers:

content-type=text/xml; charset=utf-8
connection=close
accept=*/*
depth=1
accept-encoding=gzip,deflate
sentry-trace=acd47688fc5a4b089fd144acc6953075-b4a83beb7085f7b3-0
host=<REDACTED>
baggage=sentry-environment=production,sentry-release=0.0.135,sentry-public_key=492d32ff2b584c1a9accc63781911feb,sentry-trace_id=acd47688fc5a4b089fd144acc6953075,sentry-sample_rate=0.05
content-length=483
authorization=<REDACTED>
user-agent=Morgen Backend CalendarAgent

hope this helps!

[DeepDiver1975]

So it happens on querying the calendar for events .... we need to look at the already stored events in the database and see which one is broken and how it got there ...

Which is kind of strange (unless my memory plays tricks on me) any event is validated before written into the db ...

[bbbart]

ah, so it's because of (one or more) broken event(s) in my calendar? so then the problem lies in formulating the response, not in parsing the request?

they were all imported en masse after migrating from Radicale using https://github.com/pimutils/vdirsyncer/ (to/from my local filesystem), but I guess that also makes them go through the validation system in place, right?

[DeepDiver1975]

No idea how vdirsyncer works :shrug:

ah, so it's because of (one or more) broken event(s) in my calendar? so then the problem lies in formulating the response, not in parsing the request?

Yes - the calendar query hits the dav server which is grabbing relevant events from db and then parses them to do further processing and build the response.

At the end calendar query implementation needs to be hardened to handle such situations....

[bbbart]

that's interesting. so, would it be a good idea to run the afflicted code (as discussed in https://github.com/sabre-io/Baikal/issues/1085#issuecomment-1418295860) against all events in our DB to check which one(s) cause(s) the error? would it help you if I tried this?

about the end calendar query implementation: I believe in this case of course nothing was received by Morgen to harden against in the first place.