Skip to content

fix: replace a ghost of a deleted test calendar - #49

Merged
tobixen merged 3 commits into
mainfrom
fix/zimbra-ghost-calendar
Oct 30, 2026
Merged

tobixen merged 3 commits into
mainfrom
fix/zimbra-ghost-calendar

Conversation

@tobixen

@tobixen tobixen commented Oct 29, 2026

Copy link
Copy Markdown
Member

Commit message:

fix: replace a ghost of a deleted test calendar

Zimbra 10 relocates a calendar created with a display name.  After the
relocated calendar is deleted, its cal_id keeps answering PROPFIND and
REPORT for a while, as an empty calendar that is not listed and answers
500 to every PUT; a DELETE of it is a 204 that changes nothing.  The
next run reused it and failed from the start.  A leftover under one of
our cal_ids (main, tasks, journals) is now used as the principal lists
it, by path or display name; one not listed is put to a test write, and
only if that fails is it replaced by a MKCALENDAR.

Prompt: Clean-up of Zimbra: the tests has to be able to clean up from previous test runs, it should not be needed to do manual cleanup after aborted test runs ...
Prompts (comments made inline in the document while reviewing it):
> (on suggestions on how to fix "A server with an incomplete calendar listing loses its leftovers and aborts") I'm not much concerned about more requests ... it's important that the fix makes things robust and resilent (sic) on every server.

Assisted-By: Claude Opus 5.5 <noreply@anthropic.com>
Reviewed-by: Tobias Brox <tobias@redpill-linpro.com>

Also piggy-backing: docs: TODO on following the zimbra profile rename (from the review of python-caldav/caldav#839).

Zimbra 10 relocates a calendar created with a display name.  After the
relocated calendar is deleted, its cal_id keeps answering PROPFIND and
REPORT for a while, as an empty calendar that is not listed and answers
500 to every PUT; a DELETE of it is a 204 that changes nothing.  The
next run reused it and failed from the start.  A leftover under one of
our cal_ids (main, tasks, journals) is now used as the principal lists
it, by path or display name; one not listed is put to a test write, and
only if that fails is it replaced by a MKCALENDAR.

Prompt: Clean-up of Zimbra: the tests has to be able to clean up from previous test runs, it should not be needed to do manual cleanup after aborted test runs ...
Prompts (comments made inline in the document while reviewing it):
> (on suggestions on how to fix "A server with an incomplete calendar listing loses its leftovers and aborts") I'm not much concerned about more requests ... it's important that the fix makes things robust and resilent (sic) on every server.

Assisted-By: Claude Opus 5.5 <noreply@anthropic.com>
Reviewed-by: Tobias Brox <tobias@redpill-linpro.com>
Prompt: [file the review finding on caldav's commit splitting the zimbra profile]

Assisted-By: Claude Opus 5.5 <noreply@anthropic.com>
Reviewed-by: Tobias Brox <tobias@redpill-linpro.com>
caldav renames its zimbra compatibility profile zimbra_8_8 and adds
zimbra_10_1 (python-caldav/caldav#839).  The
--caldav-features help text, a docstring and the example in USAGE.md
still named the old one; the TODO on following the rename goes.

Prompt: if (sic) the caldav-server-tester help text in master, without pushing [fix the help text and docstring that still name caldav's old `zimbra` profile]

Assisted-By: Claude Opus 5.5 <noreply@anthropic.com>
Reviewed-by: Tobias Brox <tobias@redpill-linpro.com>
@tobixen
tobixen merged commit bcf5d98 into main Oct 30, 2026
12 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant