Three merges in 40s raced the release version plan; PyPI 0.4.30 was built from a commit two merges behind its tag #1016

On 2026-08-21 between 15:05:37 and 15:06:13 UTC, three PRs merged to main (#1011 → 5611aea, #1009 → a94d6c1, #1013 → e2692cd). Their three release.yml runs overlapped and came out inconsistent.

Two separate defects fall out of that.

The version plan is not serialized against tag pushes. The first run published dirsql-py 0.4.30 but its py tag never landed. The third run therefore read the latest py tag as 0.4.29, planned 0.4.30 a second time, built five wheels plus an sdist for it, and PyPI rejected the upload as a duplicate. Any two merges close enough together can do this again; the 40-second window here was not unusual.

A run whose publish failed still wrote the tag. dirsql-py-v0.4.30 now points at e2692cd, but the artifact on PyPI under that version was built from 5611aea, two merges earlier. Tagging is not gated on the publish it describes, so the tag records a release that never happened from that tree.

Impact this time: provenance only

The wheels on PyPI are functionally correct, which is why this did not surface as a user-visible break.

• Rewrite search-by-meaning around vec0; enforce the distcheck platform mirror #1009 changed only docs/, internals/checks/, internals/distcheck/ and a workflow. Nothing under a published package's globs.
• Audit the window the vacuous unit mutation gate left unmutated, and kill what escaped #1013 changed packages/rust/src/lib.rs and matcher.rs, but every added line sits inside an existing #[cfg(test)] module. No runtime code.

So a wheel built from e2692cd would behave identically to the one built from 5611aea. crates.io 0.4.25 and npm 0.4.29 both came from e2692cd and are current. Nothing needs republishing — but the next occurrence will not necessarily be this benign, since the same race can drop a real source change.

Suggested fix

Both defects are in the release lane rather than in dirsql source, so this likely wants an upstream putitoutthere change (and possibly its own issue there):

1. Serialize the plan against the tag push, or compute the next version from a source that a concurrent run cannot observe stale — a concurrency group on the publish lane keyed to the package rather than the ref would be the blunt version.
2. Push a package's tag only after that package's publish succeeds, so a failed publish leaves no tag to mislead the next plan.
3. Treat 400 File already exists as a hard error worth naming in the log — it currently reads as a generic upload failure, and the duplicate-version cause took a log dig to find.

Leaving dirsql-py-v0.4.30 in place for now: retagging rewrites published history for no functional gain. Reconsider if the audit trail matters more than the churn.