test(e2e): demote the cargo production legs to canary status — free cargo tier is unpublished - #235
Open
Mikola Lysenko (mikolalysenko) wants to merge 3 commits into
Open
Conversation
…argo tier is unpublished Production deleted both pinned traitobject patches between 2026-08-27 and 2026-08-28 (0.1.1/cf2e6f58 for the hosted/vendored suites, 0.0.1/b15f2b7f for the safety round-trip), and now publishes no free-tier patch for ANY cargo crate — probes of every RUSTSEC-advisoried crate and the top 1000 crates.io packages all return empty, while the npm/pypi/gem pins remain live. With nothing to pin, the cargo install proofs cannot run; this has kept hosted-e2e and the three e2e_safety_cargo_build legs red on main since 2026-08-28. Move cargo onto the UNPUBLISHED_ECOSYSTEMS watchlist in both production suites, exactly as maven/nuget/composer are handled: the canaries keep probing production each run and, under the CANARY_STRICT knobs, nag when a free cargo patch appears again so the install proofs can be restored. Retire traitobject_real_socket_patch_round_trip (its oracle was that specific patch's compile_error!) and the cargo-only helpers nothing else references. Docs get the corrected catalog/coverage tables plus a dated demotion note; re-promotion is the existing withdrawn-patch procedure with this commit's history as the restore template. Verified: safety suite 5/5; hosted suite 15/15 live against production under SOCKET_PATCH_HOSTED_E2E_STRICT=1; vendored suite 11/12 (the one red is pre-existing server-side gem-catalog drift, untouched by this change); CI's clippy invocation clean; no traitobject reference remains outside get.rs's mocked unit tests. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
release-readiness regenerates the lock with the runner's npm 10, which does not write the `libc` platform arrays npm >= 11 emits — so the npm-11-shaped lock from #233 makes 'version-sync.sh 4.0.0 is not a no-op' fail on every PR and on main. The check's npm is the effective canon; note the npm-major dependence for whoever next refreshes the lock locally. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
The release-readiness gate re-runs version-sync.sh and compares the regenerated npm/socket-patch/package-lock.json byte-for-byte, so the lock's canonical shape is defined by whatever npm regenerates it. npm 11 adds libc arrays that npm 10 omits, which is how the #233 refresh (made locally with npm 11) broke the gate under CI's npm 10 — and the same drift would recur in reverse the day the runner image jumps to npm 11. Pinning the refresh via npx makes the gate independent of both the runner default and the developer's local npm; bumping the pin now takes a deliberate commit that refreshes the lock alongside it. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
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 join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
Summary
hosted-e2eand the threee2e (e2e_safety_cargo_build)legs have been red on main since 2026-08-28. Root cause: production deleted both pinned traitobject patches (0.1.1/cf2e6f58…for the hosted/vendored suites,0.0.1/b15f2b7f…for the safety round-trip —/patch/view404s,/patch/by-packagereturnspatches:[]), and now publishes no free-tier patch for any cargo crate at all: live probes of every crate in the RUSTSEC advisory DB (915) and the top 1,000 crates.io packages by downloads all come back empty, while the npm (minimist), pypi (urllib3 ×3), and gem (activestorage ×5) pins remain live. With no live patch to pin, a replacement re-pin is impossible; the cargo install proofs cannot run.This demotes cargo to the same status as maven/nuget/composer — ecosystems with no free-tier patches, watched by the canary pattern:
e2e_hosted_production.rs/e2e_vendored_production.rs: cargo joinsUNPUBLISHED_ECOSYSTEMS(probing openssl/tokio/hyper/smallvec per the existing per-suite candidate conventions); theCARGO_*catalog constants, preflight registrations, andcargo_hosted_install_proof/cargo_vendored_install_prooflegs (plus cargo-only helpers) are removed. The canaries keep hitting production every run and, under the*_CANARY_STRICTknobs, nag when a free cargo patch appears again — the re-promotion tripwire.e2e_safety_cargo_build.rs:traitobject_real_socket_patch_round_tripretires — its build oracle was that specific patch'scompile_error!, so no other patch can substitute without a rewrite. The suite's other 5 local-fixture tests are untouched (file/suite name unchanged; the ci.yml matrix needs no edits).This intentionally drops cargo install-proof coverage (step-5 "package manager independently fetches from patch.socket.dev") until the free cargo tier is live again.
Also carries PR #234's
release-readinessfix (2026-09-02)This PR and #234 were deadlocked: #234 (npm wrapper lock regenerated with CI's npm 10 +
version-sync.shpinned tonpx --yes npm@10) was red only on the four cargo legs this PR fixes, and this PR was red only onrelease-readiness, which #234 fixes. Neither could go green alone, so #234's two commits are cherry-picked here verbatim (278eefe,47f1c05):npm/socket-patch/package-lock.json: drops the 8libcarrays npm ≥ 11 wrote in fix(maven): send the official Maven CLI user agent to the maven2 registry; refresh npm wrapper lock for published 4.0.0 platform packages #233's refresh; npm 10 (the CI runner default) strips them duringversion-sync.sh, which made the "version-sync is a no-op" gate fail on every branch off main.scripts/version-sync.sh: pins the lock refresh tonpx --yes npm@10(NPM_LOCK_REFRESH_VERSION) so the gate's canon no longer depends on whoever last ran the refresh. Bumping the pin means refreshing the lock in the same commit.Verified locally on this branch:
bash scripts/release-lint.sh --sync-only→version coherence OK: every stamped site already carries 4.0.0, tree clean afterwards (local npm is 11.19; the pin is what makes it byte-stable).Once this merges, #234 is fully superseded (its diff against main becomes empty) and should be closed.
Verification (live against production, 2026-09-01)
--ignored, mirrors the CI legs)SOCKET_PATCH_HOSTED_E2E_STRICT=1— preflight green, canary reportscargo / maven / nuget / composerand passesgem_bundler_vendored_install_proof) is pre-existing server-side gem-catalog drift (production wired activestorage@6.0.3 to the fifth patch9c2b4925…and added actionpack/activesupport patches; the failing assert is byte-identical to main). Follow-up: extend the vendoredGEM_PATCHEStable.cargo clippy --workspace --all-features -- -D warnings) passes; the three edited test targets are also clean under--testsrg -i traitobjectovercrates/anddocs/hits onlyget.rs's mocked unit tests (offline repro labels, deliberately kept)🤖 Generated with Claude Code