Skip to content

Commit dfc6bd2

Browse files
committed
docs: TODO: drop the section-name entry
#809 gave extract_conn_params_from_section() its section_name, and plann passes it in PyCalendar/plann#81, so nothing is left of the entry. Prompt: [fix issues found during the review process of merging #808] Assisted-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> Reviewed-by: Tobias Brox <tobias@redpill-linpro.com>
1 parent 9828e7a commit dfc6bd2

1 file changed

Lines changed: 0 additions & 4 deletions

File tree

‎docs/design/TODO.md‎

Lines changed: 0 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -44,10 +44,6 @@ A response whose `Content-Type` says XML but whose body is not XML (an HTML erro
4444

4545
`TestServer.claim_server()` in `tests/test_servers/base.py` polls for the flock (up to `PYTHON_CALDAV_TEST_SERVER_LOCK_TIMEOUT`, 30 minutes by default) while holding the module-wide `_session_locks_mutex`. A thread waiting for one busy server therefore blocks every other thread claiming a different server, which contradicts "runs against different servers proceed in parallel". Harmless for single-threaded pytest. Fix: hold the mutex only around the `_session_locks` checks and inserts, with a per-name lock against double claims. Found in the review of https://github.com/python-caldav/caldav/pull/776.
4646

47-
## Config errors from extract_conn_params_from_section name no section
48-
49-
`extract_conn_params_from_section()` in `caldav/config.py` passes the fixed name `"section"` to calendaring-config's `section_connection()`, so a failing `password_command` reads "password_command of section section exited with status 3" for plann users. Fix: an optional `section_name` parameter, passed on, and plann giving its section names. Found in the review of plann's switch to caldav 3.6, see https://github.com/python-caldav/caldav/issues/786.
50-
5147
## calendar_multiget() fails on an async client
5248

5349
`Calendar.calendar_multiget()` in `caldav/collection.py` does `list(self.multiget(...))`, but `multiget()` returns a coroutine for an async client, so the call raises `TypeError`. `calendar_multiget()` has no return annotation, so a type checker does not catch it. Fix: return `self.multiget(...)` for an async client (or annotate it like `multiget()`), with an async unit test. Found in the review of the fix for https://github.com/python-caldav/caldav/issues/799.

0 commit comments

Comments
 (0)