Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Principal.calendar_home_set and get_calendars() disagree on where calendars live without a calendar-home-set

Closed
  • Is something wrong?
#749 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

@Ehsan-hash is already working on this.

Since Oct 12, 2026.

  • #755 by @Ehsan-hash — open

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
52/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
python
Domain
backend, databases

Research direction

Read Principal.calendar_home_set in caldav/collection.py alongside BaseDAVClient._calendar_home_urls() and trace how Principal.calendar(), make_calendar(), and _async_get_calendar_home_set() use the property. Check the iCloud host-switching behavior in the setter and run the GMX-related tests to compare discovery and calendar creation paths. Done means both paths use the same fallback order and synchronous and asynchronous behavior remain consistent.

Written by the indexing model from the issue text.

Description

Disclaimer: AI-generated text below the line, generated by Claude Opus 5.5 (Claude Code) while reviewing https://github.com/python-caldav/caldav/pull/744, from the prompts:

Look into #744
Rebase and fix issues

On a server that advertises no calendar-home-set, the two discovery paths look in different places:

  • client.get_calendars() / Principal.get_calendars() (BaseDAVClient._calendar_home_urls()) search the principal URL first (the GMX fallback), and since https://github.com/python-caldav/caldav/pull/744 the client URL only when the principal holds no calendars.
  • Principal.calendar_home_set (caldav/collection.py, the setter) falls back to client.url: URL.objectify(None) is None, and client.url.join(None) is the client URL. Principal.calendar(name=..., cal_id=...), Principal.make_calendar() and their async twins go through this property.

So on GMX-like servers principal.get_calendars() can list calendars that principal.calendar(cal_id=...) will not resolve against the same base, and make_calendar() creates below the client URL rather than below the principal where the calendars were found. The inconsistency predates PR 744 - the GMX fallback in get_calendars() was added without touching the property.

Possible fix: have Principal.calendar_home_set use the same fallback order as _calendar_home_urls() (principal URL, then client URL), sharing the logic rather than duplicating it. Needs care for the async lazy path (_async_get_calendar_home_set()) and the icloud host-switching side effect in the setter.

(It's needed to get tests working under GMX again to see how it behaves)

Dominant language
Python
Stars
412
Forks
113
Avg merge
1d 7h
Merged PRs (30d)
34

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from python-caldav/caldav

All issues in python-caldav/caldav

Similar issues

More Python issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.