Skip to content

test, build: per-server test-server lock; v[0-9]* version tags - #776

Merged
tobixen merged 4 commits into
masterfrom
test/server-session-lock
Oct 14, 2026
Merged

tobixen merged 4 commits into
masterfrom
test/server-session-lock

Conversation

@tobixen

@tobixen tobixen commented Oct 14, 2026 •

Copy link
Copy Markdown
Member

Code and text AI-generated (Claude Opus 5.5); each commit message records the prompts.

Test and build housekeeping; the only library code touched is the test-server fallback in caldav/config.py:

  • Per-server session lock for parallel test runs. Concurrent pytest runs (e.g. from several worktrees) shared the docker, embedded and external test servers and clobbered each other's calendars, and one run's teardown could stop a container another run still used. start() now takes an exclusive flock per server, held until the process exits; runs against different servers proceed in parallel. The wait is capped (default 30 min, PYTHON_CALDAV_TEST_SERVER_LOCK_TIMEOUT), and get_davclient()'s test-server fallback only probes the lock and moves on to the next server.
  • Version only from v[0-9]* tags. hatch-vcs' default describe matches any tag with a number in it, so a non-release tag could become the version and break local builds.
  • A TODO entry for a gap found while reviewing this: the search-cache delay does not count writes from other clients.

Commits:

  • dc853e0 test: per-server session lock for parallel runs
  • 156b1b3 build: only take versions from v[0-9]* tags
  • 8f5199f docs: note search-cache delay misses other clients

Comment thread tests/test_servers/base.py Fixed
Comment thread tests/test_servers/test_base.py Fixed
@tobixen tobixen changed the title test: per-server session lock for parallel runs test: per-server session lock; build: take versions only from v[0-9]* tags Oct 14, 2026
Concurrent pytest runs (e.g. from several worktrees) share the docker,
embedded and external test servers, so they clobbered each other's
calendars, and one run's teardown could stop a container another run
still used.  start() now takes an exclusive flock per server, held until
the process exits; a second run on the same server waits, runs on
different servers proceed in parallel.  Random test order can make two
runs deadlock, so the wait is capped (default 30 min), after which tests
on that server fail at once.  get_davclient()'s test-server fallback
only probes the lock and moves on to the next server.  A claim that
fails halfway closes its lock file, so no leaked file keeps holding
the lock.  The setup hook is now installed for servers already running
at collection too, so every test goes through start() and the lock; a
docker server always gets a teardown, as a waiting run may restart it.

Prompt: we now have multiple pytest runs (...), in different workbranches, but towards the same set of docker test calendar servers.  This may clobber up.
Followup-Prompt: Perhaps one lock file per test server.  It can be very useful to run tests towards different servers in parallell, and that should be safe enough
Followup-Prompt: go [implement the per-server lock: holder pid in the lock file, wait timeout, setup hook always calling start()]
Followup-Prompt: please look into the code quality problems [flagged by GitHub code quality on #776: lock files left open when a claim fails]

Assisted-By: Claude Opus 5.5 <noreply@anthropic.com>
Reviewed-by: Tobias Brox <tobias@redpill-linpro.com>
hatch-vcs' default describe matches any tag with a number in it, so a
non-release tag could become the nearest tag and break local builds
with "Can't parse version from tag".  Restrict describe to release
tags.

Prompt: For some of my python-libraries, [tags with numbers in them] can break local hatch-vcs builds, because hatch-vcs tries to read it as a version number.  This has been fixed somewhere but not everywhere.  Please check [and] fix it wherever it's relevant

Assisted-By: Claude Opus 5.5 <noreply@anthropic.com>
Reviewed-by: Tobias Brox <tobias@redpill-linpro.com>
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 test/server-session-lock branch from 365afbd to 8f5199f Compare October 14, 2026 20:11
Comment thread tests/test_servers/test_base.py
@tobixen tobixen changed the title test: per-server session lock; build: take versions only from v[0-9]* tags test, build: per-server test-server lock; v[0-9]* version tags Oct 14, 2026
get_davclient()'s test-server fallback called claim_server() on every
server, but the caldav.testing and config-file servers that a
pip-installed caldav uses have none, so every server was skipped.  A
server that failed to start also kept its claim until the process
exited.  Without fcntl (Windows), embedded and external servers now
start unlocked instead of failing; docker servers still need fcntl.

Prompt: dismiss the false positive and merge 776.  Leave 768 for a while
[the false positive: a CodeQL "file is not always closed" warning on a
test fixture; 776 is #776 -
its merge review found the bugs fixed here; 768 is
#768, unrelated]
Followup-Prompt: do the needful [fix the bug the merge review found -
the fallback skipping every server of a pip-installed caldav - plus the
claim left held after a failed start and the missing fcntl on Windows]

Assisted-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Reviewed-by: Tobias Brox <tobias@redpill-linpro.com>
@tobixen
tobixen merged commit 8bf4738 into master Oct 14, 2026
19 checks passed
@tobixen
tobixen deleted the test/server-session-lock branch October 14, 2026 22:12
tobixen added a commit that referenced this pull request Oct 14, 2026
A thread waiting in claim_server() holds the module mutex, so claims
on other servers wait too.  Harmless for single-threaded pytest, so
recorded rather than fixed.

Prompt: /verify-quit do the needful [end-of-session audit; it listed
this minor issue, found in the review of
#776, as untracked]
Followup-Prompt: file #2 [= record that issue in docs/design/TODO.md]

Assisted-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
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