51 releases 59 tags

RSS feed

• v0.8.1 dca80226a4

  Compare

  v0.8.1 Stable

  joeyr released this 2026-08-09 19:53:19 -05:00 | 99 commits to main since this release

  update_event and delete_event did not work against iCloud at all. Every call
  failed on the lookup, before touching anything.

  Fixed

  • An event is now fetched by its resource URL instead of searched for by UID.
    0.8.0 resolved a handle with caldav's get_event_by_uid, which issues a
    calendar-query REPORT filtering on UID. iCloud answers that with 412
    Precondition Failed — caldav's own source lists
    get_object_by_uid_is_broken among the iCloud quirks — so both write tools
    failed at _load_for_write on every call:

    ERR caldav/write > could not load event for writing | error=ReportError at '412 Precondition Failed'
    ERR tool/delete  > delete_event failed | error=CalendarUnavailable: Could not read that event back
    

    Nothing was ever modified, and the error envelopes reported that correctly —
    the failure was total rather than partial, which is the one thing that went
    right. A CalDAV resource is addressed by URL, and the href came back with the
    read that issued the handle in the first place; searching for it again was
    doing the work twice, through the one query shape this server cannot rely on.

  • event_id now carries the resource filename as a third field. The
    encoding is internal and no tool signature mentions its contents, so this is
    not a breaking change to the API — but handles issued by 0.8.0 name no
    resource and are refused with "list the events again" rather than resolved.
    Since no 0.8.0 handle could ever be written through, nothing that worked
    before stops working.

    The filename only — ABC-123.ics, never the path it hangs off, which is
    /<dsid>/calendars/<collection>/ and carries the account identifier. The URL
    is rebuilt server-side against the calendar the allowlist already resolved, so
    a handle still cannot point a write at a calendar it does not name.

  • An event whose resource filename is unknown gets no event_id, which
    extends the existing rule rather than adding one: a handle that cannot be
    resolved is worse than no handle, and absence already means "not editable" for
    repeating events, subscriptions and read-only calendars.

  • A resource that no longer holds the event it was read as is refused. An
    href can be reused after a delete, and editing whatever moved in — under the
    old event's title — is the one outcome worse than failing.

  Testing

  The fake CalDAV handle now raises 412 on get_event_by_uid the way iCloud
  does, so the 0.8.0 bug fails the suite instead of passing against a fake more
  capable than the real server. Reverting the fix fails 17 tests, six of them new,
  including a full read-to-write round trip — list_events, take the event_id
  off an event, delete it — which nothing covered before. That gap is exactly how
  a total outage of both write tools shipped green.

  Downloads

  • Source code (ZIP)
    0 downloads
  • Source code (TAR.GZ)
    0 downloads