The watcher thread crashed in production with "database is locked", and
under load the damage is worse than a stalled rescan:
sqlite3.InterfaceError: bad parameter or other API misuse
TypeError: 'NoneType' object is not subscriptable
Radicale serializes its request threads with Storage.acquire_lock, but the
watcher calls index.rescan() outside it. Both share one sqlite3 connection,
and rescan is a multi-statement read-modify-write — bump the generation,
reparse, reconcile identities, prune, commit. Interleaving two of those
corrupts the reconcile pass and misuses the connection.
Give Index an RLock and take it in every public method. Writer holds it
across validate → write → reindex, since a rescan landing between _load
and the splice would invalidate the byte spans about to be written.
Two supporting fixes:
- _rebuild_memory assigned an empty dict before refilling it, so a reader
could observe a half-populated task list. Build, then swap.
- Open the database in WAL with a 30s busy_timeout, so `mdcaldav doctor`
run against a live server waits instead of failing.
This is also a second, independent cause of the ETag churn fixed in
2552545: a corrupted reconcile pass reassigns last_modified on tasks that
never changed.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Completing a task in a CalDAV client wrote through to the markdown
correctly, then the client silently un-completed it moments later.
`to_ics` stamped DTSTAMP and LAST-MODIFIED with the wall clock on every
serialization, and Radicale derives an item's ETag by hashing that
serialization. So an unchanged task minted a fresh ETag on every read, at
one-second granularity. A client that read the task, waited for the user
to tick the checkbox, then PUT with `If-Match: <the etag it holds>` always
got 412 Precondition Failed — and resolved that apparent conflict by
re-downloading the server copy, discarding the completion.
Persist a per-task `last_modified` in the sidecar instead, stamped only
when the task's content or status actually changes, and serve DTSTAMP,
LAST-MODIFIED and the Item's own last_modified from it. The ETag is now
stable while the task is, and changes exactly when the task does.
Schema goes to v2, migrated in place with ALTER TABLE: rebuilding the
database would regenerate every UID and replace clients' whole task list.
Also fixes a plain GET of an item returning 500 — Radicale asserts on
`Item.last_modified`, which was never passed. Only REPORT was covered by
tests, so nothing caught it.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
