Open smurfix opened 1 week ago
I'd like to write up a "caldav server compatibility checker"-tool, it's currently a pain that no caldav servers are perfect enough to not break the tests.
Try this
caldav_servers = [
{
'url': ...,
'username': ...,
'password': ...,
'incompatibilities': compatibility_issues.redicale
},
]
I did that too. tests/test_caldav.py::TestScheduling::testInviteAndRespond - AssertionError
breaks anyway.
That's strange,'no_scheduling'
is included in that list.
Hm. When I try, with the master branch, and radicale-3.2.3-1
installed through archlinux, I now get two errors:
FAILED tests/test_caldav.py::TestLocalRadicale::testTodoDatesearch - caldav.lib.error.ReportError: ReportError at '500 Internal Server Error
FAILED tests/test_caldav.py::TestLocalRadicale::testRecurringDateSearch - AssertionError: assert 0 == 1
I will see if I get time to look more into it during the day ... but this is not the same errors as you observe?
Don't worry, I see those two too. :-/
I'm a bit swamped those days, but I will try to look into those two during the day at least.
It's weird, because I don't think it's that long since last I ran the test towards Radicale. Perhaps a new version is out with degraded compatibility.
So the testTodoDatesearch
(perhaps the test deserves a better name) causes a 500 Internal Server Error while doing a timestamp search for tasks. It's quite common that calendar servers yields a 500-error when throwing difficult corner cases on them - I would claim this is a server error - but the workaround is quite easy, just add 'no_todo_datesearch'
to the compatibility issue list.
The testRecurringDateSearch
is more difficult to work around. Radicale is apparently doing server-side recurring event expansion wrongly. The newer versions of the library does support client-side event expansion, but it's currently only done when the server is obviously not supporting expansion.
Possible workarounds/solutions:
I don't like the second option, as it may cause subtle changes in how the library works in production environments, breaking backward-compatibility. The third option is possibly the best, but requires most work - and it should be well thought through. I think the last option will be too bloated.
So I'll go for the first option as a temp workaround just to get the tests working (again), and the third option will be for a later release.
conf_private.py:
Radicale versions tested: 3.1.8, 3.2.3