Skipped event with missing 'vevent' property (Home Assistant)

[dreimer1986]

As there is no real reason to be found in the HA CalDAV module, I try to pass things over to your issues, too.

First, the open report: home-assistant/core#74196
It includes Logs of caldav Python module on DEBUG, so maybe you have an idea?

The recent beta updated the dependencies to 0.9.1 and after that things started to change a bit. Before that the module was unable to connect to my work CalDAV server at all (Error 403), now it does progress further, but every parsing of the server causes thousands of "Skipped event with missing 'vevent' property" errors in Home Assistant. These are not due to really missing anything, but due to thousands of error 404 returned and thus empty entries being parsed. At least that is my interpretation of the logs. Sure if that is the case, that's a error that should be caught and handled, but the bigger question is, why does this happen? I am able to load some entries by hand with the entries in the log that did not error out. The server itself is working fine on Mac and a few Android apps for CalDAV, but I am very sure that it's everything, but RFC conformant. So it's not really a big flaw or something as the ones who should start to fix things are the creators of our CMS, but as I said, the apps I tested work fine with it.

If you need further information, I happily provide these. A test account would be quite impossible as it's our work calendar. We could meet with a Teamviewer session though if you need some more information I can not provide otherwise.

[tobixen]

I was doing a quick grep for the word "Skipped" in the caldav library and found nothing. Perhaps the error is coming from the vobject library. I had a hypothesis that the 404 caused empty strings to be sent to the vobject library, but apparently not ... that seems to cause an exception ...

>>> vobject.readOne("")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python3.10/site-packages/vobject/base.py", line 1155, in readOne
    return next(readComponents(stream, validate, transform, ignoreUnreadable,
StopIteration

I'm not sure when I will have time to look more into this, quite busy days and my capacity today is a bit reduced - apparently I've caught some virus.

[dreimer1986]

Take all time you need. I am in absolutely no hurry here. Just wanted to pass on the new behavior.

[tobixen]

The error message itself comes from HomeAssistant. I'll close this one - I think further research should be done in the HomeAssistant issue report, and then we can rather reopen this issue if the problem is in the caldav library.

[tobixen]

I leave it to @dreimer1986 to check my hypothesis - this fails because the server only delivers the URL and metadata, and not the data itself when presented with a (date) search.

An easy fix would be to make sure the objects are loaded in the search method ... [obj.load() for obj in objs if not obj.data]. The problem with that is that it may cause a lot of overhead, and perhaps the caller is only interested in the first 10 objects out of 1000. We may also possibly add a boolean load=true-parameter to the search method so that the client caller may opt out of the time-consuming loading ... but it does add some extra complexity to the code.

First thing is probably to check up on the RFC to see if the server is supposed to deliver data or not.

[tobixen]

I've read through the RFC. The REPORT-request sent from the caldav library explicitly asks for the calendar data, so it's a bug that it's not delivered. I will make a workaround in the library to load all the objects that comes without the calendar data, and release v0.12 ... in "some few days", though the definition of "few" may vary dependent on my work load and how many other problems I find during the next few days. I'm pretty sure it won't pass several months, though :-)

[tobixen]

Is your calendar very dynamic? I did a search, got out the list of URLs, then tried to do a load() on those, just to get a 404 ... :-/

EDIT: perhaps better to take this over private chat. Anyway, my hypothesis that the event was disappearing before I could load it seems to be incorrect, I reran the test and it breaks on the same URL.