Hotfix release for a production incident where CalDAV sync was wrongly cancelling live customer bookings (visible to host and guest as a cancellation email with the reason "The calendar event was deleted by the host"). No schema changes, no behaviour changes outside the orphan-cancellation surface. Upgrade is recommended for any deployment running 1.10.x against BlueMind or any CalDAV server with quirky sync-collection deletion reporting.
Fixed
- Stop cancelling bookings on phantom sync-collection deletions —
delete_events_by_hrefinsrc/commands/sync.rscancelled any booking whose UID matched an href the server reported as deleted, regardless of whether the localeventstable actually had a matching row. In production, BlueMind's sync-collection emitted a "deleted" entry for an href whose corresponding event lived on a different calendar (the booking's write calendar); the global UID-onlycancel_orphaned_bookinglookup still found the confirmed booking, cancelled it, and emailed both host and guest. The cancellation is now gated onrows_affected > 0— if we never had a local event for that calendar/href, that's a server-side false positive and we log a warning instead of cancelling.
Internal
- 634 tests total (up from 632 in 1.10.1), all green on pre-commit
- New regression tests in
src/commands/sync.rs:delete_events_by_href_skips_cancellation_when_no_local_event— captures the exact prod failure modedelete_events_by_href_cancels_when_local_event_existed— guards the legitimate deletion case from regressing
Follow-ups for the next release
Three further hardening items are tracked separately:
- #105 — confirm-before-cancel via HEAD/PROPFIND on the resource href before any orphan path cancels a booking
- #106 — scope
cancel_orphaned_bookingby source/account, not by UID alone - #107 — propstat-aware sync-collection XML parser (currently misreads a
<d:status>404</d:status>inside a<d:propstat>as a resource-level deletion)