Fixes for #638 and #639 and misc 3.0.2-relevant stuff

.github/workflows/linkcheck.yml

@@ -1,18 +1,35 @@
 name: Link check
 
-on: [push, pull_request]
+on:
+  push:
+  pull_request:
+  workflow_dispatch:
+  schedule:
+   - cron: "03 22 * * *"
 
 jobs:
   linkcheck:
     runs-on: ubuntu-latest
+    permissions:
+      issues: write
     steps:
-    - uses: actions/checkout@v4
+    - uses: actions/checkout@v5
     - name: Check links with Lychee
+      id: lychee
       uses: lycheeverse/lychee-action@v2
       with:
-        fail: true
+        fail: false
         args: >-
+          --root-dir "$(pwd)"
           --timeout 20
           --max-retries 3
-          '**/*.md'
-          '**/*.rst'
+          --cache
+          --max-cache-age 14d
+          .
+    - name: Create Issue From File
+      if: steps.lychee.outputs.exit_code != 0
+      uses: peter-evans/create-issue-from-file@v5
+      with:
+        title: Link Checker Report
+        content-filepath: ./lychee/out.md
+        labels: report, automated issue

.lycheeignore

@@ -4,6 +4,7 @@ https?://.*\.example\.com/.*
 
 # Localhost URLs for test servers (not accessible in CI)
 http://localhost:\d+/.*
+http://localhost/.*
 
 # CalDAV endpoints that require authentication (401/403 expected)
 https://caldav\.fastmail\.com/.*
@@ -16,5 +17,17 @@ https://webmail\.all-inkl\.com/.*
 https://www\.google\.com/calendar/dav/.*
 https://caldav-jp\.larksuite\.com/.*
 
-# Apple namespace URL (returns 404 but is a valid XML namespace reference)
+# Misc old namespace URLs, few of them works
 http://apple\.com/ns/ical/
+http://cal.me.com/_namespace/
+http://nextcloud.org/ns
+http://owncloud.org/ns
+
+
+# Other junk that was never meant to be followed
+# lychee converts unknown schemes to file:// URLs before matching ignore patterns
+file://.*/scheme:.*
+/17149682/.*
+http://x/
+https://ecloud\.global/remote\.php/.*
+https://tobixen@e\.email/remote\.php/dav

.pre-commit-config.yaml

@@ -14,10 +14,16 @@ repos:
       - id: trailing-whitespace
       - id: end-of-file-fixer
 
+  - repo: https://github.com/compilerla/conventional-pre-commit
+    rev: v3.4.0
+    hooks:
+      - id: conventional-pre-commit
+        stages: [commit-msg]
+
   - repo: https://github.com/lycheeverse/lychee
     rev: lychee-v0.22.0
     hooks:
       - id: lychee
-        args: ["--no-progress", "--timeout", "10"]
-        types: [markdown, rst]
-        stages: [manual]  # Run with: pre-commit run lychee --hook-stage manual
+        args: ["--no-progress", "--timeout", "10", "--exclude-path", ".lycheeignore"]
+        stages: [pre-push]
+        exclude: ^tests/test_caldav_unit\.py$

CHANGELOG.md

@@ -12,6 +12,20 @@ Changelogs prior to v2.0 is pruned, but was available in the v2.x releases
 
 This project should adhere to [Semantic Versioning](https://semver.org/spec/v2.0.0.html), though for pre-releases PEP 440 takes precedence.
 
+## [3.0.2] - 2026-03-05
+
+### Fixed
+
+* Communication dump (`PYTHON_CALDAV_COMMDUMP` / `debug_dump_communication`) was accidentally dropped during the v3.0 refactor.  Restored, with the dump logic extracted into a shared helper so both the sync and async code paths benefit.  Fixes https://github.com/python-caldav/caldav/issues/638
+* `search()` raised `NotImplementedError` when a full calendar-query XML was passed and the server does not support `search.comp-type.optional` (e.g. DavMail).  Falls back to a single REPORT with the XML as-is.  Fixes https://github.com/python-caldav/caldav/issues/637
+
+### Tests and documentation
+
+* All links to the RFC is now in a cannonical format.  Links in docstrings and ReST-documntation follows the sphinx-standard.  Fixes https://github.com/python-caldav/caldav/issues/635 - pull request https://github.com/python-caldav/caldav/pull/636
+* I've decided to try to stick to the conventionalcommits standard.  This is documented in CONTRIBUTING.md, and I've added a pre-commit hookk for enforcing it (but it needs to be installed through pre-commit ... so I will most likely have to police pull requests manually)
+* Some code refactoring in the test code.
+* Improved the lychee link testing setup
+
 ## [3.0.1] - 2026-03-04
 
 Highlights:
@@ -43,6 +57,10 @@ Highlights:
 
 * The compatibility-hint key `search.comp-type-optional` has been renamed to `search.comp-type.optional` for consistency with the dotted-key naming convention used elsewhere.  If you have this key set in a local server configuration, update it accordingly.
 
+### Documentation
+
+Some minor improvements, including a fix for https://github.com/python-caldav/caldav/issues/635 - use canonical RFC-links.
+
 ## [3.0.0] - 2026-03-03
 
 Version 3.0 should be fully backward-compatible with version 2.x - but there are massive code changes in version 3.0, so if you're using the Python CalDAV client library in some sharp production environment, I would recommend to wait for two months before upgrading.
@@ -183,7 +201,7 @@ Additionally, direct `DAVClient()` instantiation should migrate to `get_davclien
 
 ### Changed
 * Optimilizations on data conversions in the `CalendarObjectResource` properties (https://github.com/python-caldav/caldav/issues/613 )
-* Lazy imports (PEP 562) -- `import caldav` is now significantly faster.  Heavy dependencies (lxml, niquests, icalendar) are deferred until first use.  https://github.com/python-caldav/caldav/pull/621
+* Lazy imports (PEP 562) -- `import caldav` is now significantly faster.  Heavy dependencies (lxml, niquests, icalendar) are deferred until first use.  https://github.com/python-caldav/caldav/issues/621
 * Search refactored to use generator-based Sans-I/O pattern -- `_search_impl` yields `(SearchAction, data)` tuples consumed by sync or async wrappers
 * Configuration system expanded: `get_connection_params()` provides unified config discovery with clear priority (explicit params > test server config > env vars > config file)
 * `${VAR}` and `${VAR:-default}` environment variable expansion in config values

CONTRIBUTING.md

@@ -1,6 +1,37 @@
 # Contributing
 
-Contributions are mostly welcome.  If the length of this text scares you, then I'd rather want you to skip reading and just produce a pull-request in GitHub.
+Contributions are mostly welcome (but do inform about it if you've used AI or other tools).  If the length of this text scares you, then I'd rather want you to skip reading and just produce a pull-request in GitHub.
+
+## Git commit messages
+
+Starting from v3.0.1, we'll stick to https://www.conventionalcommits.org/en/v1.0.0/ on the master branch.  A good pull request contains one commit that follows the conventions.  Otherwise the maintainer will have to rewrite the commit message.
+
+The types used should (as for now) be one of:
+
+* "revert" - a clean revert of a previous commit (should be used very infrequently on the master branch)
+* "feat" - a new feature added to the codebase/API.  The commit should include test code, documentation and a CHANGELOG entry unless there are good reasons for procrastinating it.  "feat" should not be used for new features that only affects the test framework, or changes only affectnig the documentation etc.
+* "fix" - a bugfix.  Again, documentation and CHANGELOG-entry should be included in the commit (notable exception: if a bug was introduced after the previous release and fixed before the next release, it does not need to be mentioned in the CHANGELOG).  If the only "fix" is that some typo is fixed in some existing documentation, then we should use "docs" instead.
+* "perf" - a code change in the codebase that is neither a bugfix or a feature, but intends to improve performance.
+* "refactor" - a code change in the codebase that is neither a bugfix or a feature, but makes the code more readable, shorter, better or more maintainable.
+* "test" - fixes, additions or improvements that only affects the test code or the test framework.  The commit may include documentation.
+* "docs" - changes that *only* is done to the documentation, documentation framework - this includes minor typo fixes as well as new documentation, and it includes both the user documentation under `docs/source`, other documentation files (including CHANGELOG) as well as inline comments and docstrings in the code itself.
+* "other" - if nothing of the above fits
+
+The `compatibility_hints.py` has been moved from the test directory to the codebase not so very long ago.  Some special rules here:
+
+* Adjusting the feature set for some calendar server?  Check if there exists some workarounds etc in the code for said feature, if so, then it should be considered a fix or a feature.  Perhaps even a breaking change.  Otherwise, use `test: ...`.  (because it is relevant for the compatibility test, if nothing else).
+* Adding a new feature hint?  Ensure it's covered by the caldav-server-tester.  Since we have a compatibility test, it will be relevant for the test - so use `test: (...)`.  It should be covered by the caldav-serveer-tester, so refer to some issue or pull request for the caldav-server-tester in the commit message.
+* Changing some descriptions?  That goes as `docs: ...` even if it's actually changing a variable in the code.
+
+This is not set in stone.  If you feel strongly for using something else, use something else in the commit message and update this file in the same commit.
+
+"Imperative presens" or "imperative mood" is to be used in commit messages.
+
+The boundaries of breaking changes vs "non-breaking" changes [may be blurry](https://xkcd.com/1172/). In the CHANGELOG I've used the concept "potentially breaking changes" for things that most likely won't break anything for anyone.  Potentially breaking changes should be marked with `!` in the commit header.  Breaking changes should be marked both with `!` and `BREAKING CHANGE:`
+
+The conventionalcommits guide also says nothing about how to deal with security-relevant changes.  Maybe it makes sense to start the commit message (after the  "SECURITY: "
+
+As for now, we do not use the module field. If there is strong reasons for using it, then go ahead and update this file in the same commit.
 
 ## Usage of AI and other tools
 
@@ -31,11 +62,9 @@ Consider this procedures to be a more of a guideline than a rigid procedure.  Us
 
 * Write up your changes
 
-* Run `pytest` for a quick run of the tests.  They should still pass.
-
-* Run `tox -e style` to verify a consistent code style (this may modify your code).
+* Run `pytest`.  The tests should still pass.  (Beware: tests may take very long time to run and may consume a lot of memory and disk space if the tests have the permissions to start docker containers).
 
-* Consider to write some lines in the documentation and/or examples covering your change
+* Consider to write some lines in the documentation, changelog and/or examples covering your change
 
 * Add an entry in the `CHANGELOG.md` file.
 

caldav/async_davclient.py

@@ -527,6 +527,9 @@ async def _async_request(
         if response.status in (401, 403):
             self._raise_authorization_error(str(url_obj), response)
 
+        if error.debug_dump_communication:
+            error._dump_communication(method, url, combined_headers, body, response)
+
         return response
 
     # ==================== HTTP Method Wrappers ====================