Skip to content

fix: GMX create-calendar is capped, not fragile - #854

Merged
tobixen merged 4 commits into
masterfrom
fix/gmx-calendar-cap
Nov 11, 2026
Merged

tobixen merged 4 commits into
masterfrom
fix/gmx-calendar-cap

Conversation

@tobixen

@tobixen tobixen commented Nov 9, 2026

Copy link
Copy Markdown
Member

Commit message:

fix: GMX create-calendar is capped, not fragile

The GMX create-calendar hint said fragile because one test run failed
every MKCALENDAR and the next one passed.  Probing on 2026-11-10 showed
a fixed cap: five calendars per account, the birthday calendar
included, and a 403 beyond that, from either starting count tried.
Calendars leaked by test runs explain the earlier failures.  The hint
is now full, with the cap in its behaviour text.

Prompt: regarding the gmx mkcalendar marked as fragile, I vaguely remember it was fragile as in "try again"?
Followup-Prompt: it could also be fragile like in "the quota of calendars you're allowed to have is 5"
Followup-Prompt: ... fix the behavior [and] documentation ...

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

Where no calendar could be created (Posteo, GMX and other servers with
create-calendar unsupported or fragile, or a refused MKCALENDAR with no
cal_id given), the test fixtures fell back to the first calendar the
server listed, and the tests then wiped it - possibly the user's own.
Only a calendar at the fixture's cal_id, one with "pythoncaldav-test"
in its display name or the one configured under test-calendar is used
now; otherwise the tests needing a calendar skip, saying how to opt in.

Prompt: [pick from the task list: "Stop integration tests from wiping a borrowed calendar without explicit opt-in"]

Assisted-By: Claude Opus 5.5 <noreply@anthropic.com>
Reviewed-by: Tobias Brox <tobias@redpill-linpro.com>
The GMX create-calendar hint said fragile because one test run failed
every MKCALENDAR and the next one passed.  Probing on 2026-11-10 showed
a fixed cap: five calendars per account, the birthday calendar
included, and a 403 beyond that, from either starting count tried.
Calendars leaked by test runs explain the earlier failures.  The hint
is now full, with the cap in its behaviour text.

Prompt: regarding the gmx mkcalendar marked as fragile, I vaguely remember it was fragile as in "try again"?
Followup-Prompt: it could also be fragile like in "the quota of calendars you're allowed to have is 5"
Followup-Prompt: ... fix the behavior [and] documentation ...

Assisted-By: Claude Opus 5.5 <noreply@anthropic.com>
Reviewed-by: Tobias Brox <tobias@redpill-linpro.com>
Xandikos answers a write with 423 while its git index.lock is held by
another write, and a retry after a short sleep succeeds.  The design
now counts 423 as a class (C) status, opt-in via status_forcelist,
asks whether it should be retried by default (Q7), and adds a section
(4.6) on the immediate PUT retry in _post_put, which should leave
class (C) statuses alone.

Prompt: (traceback from plann's panic postponement pasted, ending in "PutError at '423 Locked'" from caldav's _post_put)
Followup-Prompt: I think we have a github issue and some design document on "retry logic in the caldav library".  Please find and add the 423-retry into the same design document.  Fix the try-and-continue in plann. [the plann fix went into the plann repository]
Followup-Prompt: the doc change should piggy-back another PR.  If there are no other PRs in progress, then add a /calendar-task to get it pushed. [it went onto this PR]

Assisted-By: Claude Opus 5.5 <noreply@anthropic.com>
Reviewed-by: Tobias Brox <tobias@redpill-linpro.com>
The changelog fragment for the calendar-wipe fix still listed GMX among
the servers where create-calendar is unsupported or fragile.  GMX is
now `full`, with a cap of five calendars, so the fragment names the cap.

Prompt: [fix issues found during the review process]

Assisted-By: Claude Opus 5.5 <noreply@anthropic.com>
Reviewed-by: Tobias Brox <tobias@redpill-linpro.com>
@tobixen
tobixen force-pushed the fix/gmx-calendar-cap branch from b2d1b6d to 0d53fa4 Compare November 11, 2026 06:33
@tobixen
tobixen merged commit 62e0a31 into master Nov 11, 2026
17 checks passed
@tobixen
tobixen deleted the fix/gmx-calendar-cap branch November 11, 2026 08:14
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