The Xarray zarr backend tests job installs the checkout over the released wheel (Override zarr-python with branch version, .github/workflows/downstream.yml:58-60) and then loses it. The next two steps call uv run (lines 65 and 73) with working-directory: xarray, and uv run re-syncs the xarray project environment before running the command; xarray ships no lockfile and its default dev group pulls xarray[complete,types] → io → zarr>=3.0, so the sync reinstalls zarr from PyPI over the local install. The job's own Show versions step prints the result.
From https://github.com/zarr-developers/zarr-python/actions/runs/34958330402 (2026-09-15, main):
+ zarr==3.3.1.dev77+g0de60773 (from file:///home/runner/work/zarr-python/zarr-python) <- Override step
Uninstalled 2 packages in 5ms
Installed 2 packages in 2ms <- uv run re-sync
zarr 3.3.0 <- Show versions
The backend tests on line 73 run under the same uv run, so those 3096 passing tests exercised zarr 3.3.0, on PyPI since 2026-07-30.
This is the release gate. #4256 ticks "Run the downstream tests against main ... Verify that the Xarray and numcodecs integration tests pass" and cites two runs by hand: 34338567820 ("passed 2026-09-09") and 34414991933 ("re-run on 3203018c after 12 more merges"). Both print zarr 3.3.0. v3.4.0 shipped that week, and neither gate run loaded the code being released.
Every retained run of this workflow on main shows it — 6 of 6, back to the current shape in 6827a61 (#4047), which replaced pixi run -e test-py313 -- python ... with uv run python ... and kept the override step: 28968639042 (07-08) and 29399234276 (07-15) print zarr 3.2.1 while installing 3.2.2.dev*; 29509449132 (07-16) the same; 34338567820, 34414991933 (09-09) and 34958330402 (09-15) print zarr 3.3.0 while installing 3.3.1.dev*. Logs before that return 410, so I cannot speak for the pixi era.
The numcodecs zarr3 codec tests job in the same file is unaffected: its override installs the identical version string uv sync already resolved from git, so the re-sync is a no-op and Show versions correctly prints zarr 3.3.1.dev77+g0de60773.
Fix I would take: uv run --no-sync on both steps in the xarray job, so the command uses the environment the two steps above it built. On a fork at dfa18e8 the unmodified workflow installs the checkout and then prints zarr 3.4.0 on two runs (https://github.com/glaziermag/zarr-python/actions/runs/35114756497 and https://github.com/glaziermag/zarr-python/actions/runs/35114764020); with --no-sync the same job prints zarr 3.3.1.dev87+g7ee8b618 (https://github.com/glaziermag/zarr-python/actions/runs/35114865505) and the 3096 tests still pass, so the correction does not turn the job red. Calling .venv/bin/python directly would work too; --no-sync leaves the rest of the step alone.
Investigated with Claude Code (Claude Opus 5); I re-derived the run logs, the workflow lines and the commit history from the API before filing.
The
Xarray zarr backend testsjob installs the checkout over the released wheel (Override zarr-python with branch version,.github/workflows/downstream.yml:58-60) and then loses it. The next two steps calluv run(lines 65 and 73) withworking-directory: xarray, anduv runre-syncs the xarray project environment before running the command; xarray ships no lockfile and its defaultdevgroup pullsxarray[complete,types]→io→zarr>=3.0, so the sync reinstalls zarr from PyPI over the local install. The job's ownShow versionsstep prints the result.From https://github.com/zarr-developers/zarr-python/actions/runs/34958330402 (2026-09-15,
main):The backend tests on line 73 run under the same
uv run, so those 3096 passing tests exercised zarr 3.3.0, on PyPI since 2026-07-30.This is the release gate. #4256 ticks "Run the downstream tests against
main... Verify that the Xarray and numcodecs integration tests pass" and cites two runs by hand:34338567820("passed 2026-09-09") and34414991933("re-run on3203018cafter 12 more merges"). Both printzarr 3.3.0. v3.4.0 shipped that week, and neither gate run loaded the code being released.Every retained run of this workflow on
mainshows it — 6 of 6, back to the current shape in 6827a61 (#4047), which replacedpixi run -e test-py313 -- python ...withuv run python ...and kept the override step: 28968639042 (07-08) and 29399234276 (07-15) printzarr 3.2.1while installing3.2.2.dev*; 29509449132 (07-16) the same; 34338567820, 34414991933 (09-09) and 34958330402 (09-15) printzarr 3.3.0while installing3.3.1.dev*. Logs before that return 410, so I cannot speak for the pixi era.The
numcodecs zarr3 codec testsjob in the same file is unaffected: its override installs the identical version stringuv syncalready resolved from git, so the re-sync is a no-op andShow versionscorrectly printszarr 3.3.1.dev77+g0de60773.Fix I would take:
uv run --no-syncon both steps in the xarray job, so the command uses the environment the two steps above it built. On a fork at dfa18e8 the unmodified workflow installs the checkout and then printszarr 3.4.0on two runs (https://github.com/glaziermag/zarr-python/actions/runs/35114756497 and https://github.com/glaziermag/zarr-python/actions/runs/35114764020); with--no-syncthe same job printszarr 3.3.1.dev87+g7ee8b618(https://github.com/glaziermag/zarr-python/actions/runs/35114865505) and the 3096 tests still pass, so the correction does not turn the job red. Calling.venv/bin/pythondirectly would work too;--no-syncleaves the rest of the step alone.Investigated with Claude Code (Claude Opus 5); I re-derived the run logs, the workflow lines and the commit history from the API before filing.