fix(release): read the crate checksum from the sparse index - #525
Merged
Merged
Conversation
us
force-pushed
the
fix/release-republish-guard
branch
from
September 10, 2026 16:02
5497e9e to
db90e58
Compare
crates.io's /api/v1/crates/<name>/<version> response no longer carries `version.cksum` (checked 2026-09-10: absent for every crate queried), so `crate_version_cksum` returned an empty string with rc 0. `publish_crate.sh` compared that empty value straight against the local sha, so every idempotent re-publish failed as a content mismatch and told the maintainer to bump the version. The v0.34.0 release died exactly there: error: crate crw-mcp-proto@0.34.0 already exists on crates.io index crw-mcp-proto@0.34.0 content mismatch - local=8e9006f12b... remote= crates.io is immutable; cannot republish. Bump the version. The sparse index reports `8e9006f12b...` for that version, which is the sha the run had just computed locally: the upload matched and the release should have skipped it. Read the checksum from the index, which is the registry protocol and where the value is authoritative, and return non-zero when it cannot be read. `publish_crate.sh` now separates "unknown" from "different". An unverifiable upload still fails the release, because blessing it would defeat the guard, but it no longer claims the content differs or advises bumping a version over a lookup that simply failed. Pinned by six tests in the existing guard suite, which stub curl and cargo so the real scripts run with no network. All six fail against the previous code.
us
force-pushed
the
fix/release-republish-guard
branch
from
September 10, 2026 16:12
db90e58 to
ed93f39
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
publish_crate.shtreats "already uploaded" as success only when the local.cratesha matches the published one. That check has been silently broken:crates.io's
/api/v1/crates/<name>/<version>response no longer carriesversion.cksum.Checked against the live registry on 2026-09-10, the field is absent for every
crate:
So
crate_version_cksumreturned an empty string with rc 0, and the callercompared it straight against the local sha. Every idempotent re-publish therefore
failed as a content mismatch. The v0.34.0 release (run 34490023731) died there:
The sparse index reports that same
8e9006f12b...for the version, so the uploadmatched and the run should have taken the idempotent-skip path. The advice to
bump the version was wrong, and would have burned a version number over a lookup
that simply failed.
Change
crate_version_cksumreads the checksum fromindex.crates.io(the registryindex protocol, where the value is authoritative) instead of the v1 API, and
returns non-zero when the index or the version cannot be read rather than
printing nothing and succeeding.
crate_index_pathimplements the documented1/2/3/4+ prefix layout.
publish_crate.shseparates "unknown" from "different". An unverifiable uploadstill fails the release, because blessing it would defeat the guard, but it no
longer reports a content mismatch or advises a version bump when the checksum
could not be read.
crate_version_presentis unchanged: it reads.version.num, which the v1 APIstill returns.
Tests
Six tests added to the existing guard suite (
scripts/release/test_guards.py,already run by CI). They stub
curlandcargoon PATH so the real scripts runwith no network:
All six fail against the code on
mainand pass with this change; the suite is14/14 locally.
Deploy notes
Release-pipeline only, no engine or API surface is touched. The next release that
hits the already-uploaded path takes the idempotent-skip branch instead of
failing, which is what
publish-cratesneeded on the last two runs.