fix(ruby): refresh standalone Cargo.lock and check the crates.io pin

[ya-luotao]

TL;DR

The Ruby extension's committed Cargo.lock still resolved microsandbox 0.6.9 from crates.io while Cargo.toml pinned the current release exactly. Refresh it, make rake version_check reject that drift, resolve the unpatched pin in CI, re-lock it automatically after each crates.io publish, and keep the new assertion out of the one job that deliberately builds against the in-tree SDK.

Description

• sdk/ruby/ext/microsandbox/Cargo.lock resolved registry microsandbox 0.6.9 (and every microsandbox-* sibling, and even its own microsandbox-ruby entry) against an exact pin many releases ahead. Nothing caught it: every Ruby CI job runs scripts/ci/ruby-sdk-checkout.sh prepare, which swaps in the workspace lock and patches microsandbox to sdk/rust, and rb_sys does not pass --locked, so gem install silently re-resolved. The gemspec ships ext/**/*, so published source gems carried a lying lock.
• The lock cannot be refreshed at bump time: the new core crate is only published later by release.yml. So the refresh has to happen after publish.
• Refresh the lock with cargo update -p microsandbox --precise <pin> (no [patch.crates-io] active). One --precise pulls all exact-pinned sibling crates along. The branch now sits at 0.6.15, refreshed after merging main.
• rake version_check (a dependency of rake test) now collects the lock's [[package]] blocks named exactly microsandbox. No such block means the lock was not resolved from this manifest and aborts; every block with a source = "registry+..." line must name the pinned version, otherwise it aborts naming both values and the cargo update to run. The check is skipped only for a path-patched lock (blocks present but none registry-sourced, which is what CI's prepare step and rake cargo:patch_workspace produce) or a missing lock.
• New check.yml job ruby-standalone-pin (gated like ruby-source-gem, no agentd needed): reads the pin from Cargo.toml, asks https://crates.io/api/v1/crates/microsandbox/<pin> with a User-Agent, and on 200 runs cargo fetch --locked in sdk/ruby/ext/microsandbox without the prepare step or any patch. On 404 (the version-bump PR before a release) it emits a notice and skips; any other status fails. Added to the summary aggregate job.
• The job resolves and fetches rather than compiles: with the extension's default-features = false, features = ["net", "ssh"], microsandbox-filesystem's build script takes its non-prebuilt branch and requires the workspace's build/agentd, which does not exist in a registry checkout. That is a pre-existing problem with the source gem, independent of this lock, and is better handled in its own issue.
• ruby-platform-gem now runs rake cargo:patch_workspace version_check gem:stage rather than rake version_check cargo:patch_workspace gem:stage. That job builds the platform binary from the in-tree Rust SDK and never consumes the committed lock, so asserting the crates.io pin against it was out of place — and fatal on a release-bump PR, where the manifest names a version crates.io does not carry yet and the standalone lock is still on the previous release (scripts/bump-version.sh refreshes only Cargo.lock and crates/agentd/Cargo.lock). The check would abort on all four platforms, prescribing a cargo update --precise that cannot resolve until after publication, and block the very PR that has to merge before the tag can be pushed. cargo:patch_workspace moves ext/microsandbox/Cargo.lock aside before anything else, so running it first makes version_check take its documented "a patched workspace may have no lock at all" skip for the crates.io half while still asserting the gem/manifest/pin lockstep that guards the patch swap, before gem:stage compiles. The unpatched crates.io assertion stays with ruby-standalone-pin, which resolves against the registry and already skips while the pin is unpublished.
• release.yml refresh-lockfile now also waits for crates-publish, installs a stable Rust toolchain, runs cargo update -p microsandbox --precise "$VERSION" in sdk/ruby/ext/microsandbox, and includes the lock in the follow-up PR it already opens for sdk/node-ts/package-lock.json (title, commit message, body and add-paths updated). The two refreshes are independent: the job runs when either publish succeeded (!cancelled() && ... && (needs.npm-publish.result == 'success' || needs.crates-publish.result == 'success')), the setup-node, npm wait and npm install steps are guarded on needs.npm-publish.result == 'success', and the Rust toolchain and cargo update steps on needs.crates-publish.result == 'success'. Checkout and create-pull-request stay unguarded: the pinned action's README states that with no diff against the base branch no pull request is created and it exits silently. The PR body qualifies each lockfile paragraph on its publish having succeeded.
• sdk/ruby/README.md documents the lock's lifecycle.
• Decisions for maintainers:
  • The CI job skips on a 404 from crates.io. The alternative is to run it unconditionally with continue-on-error, which keeps a visible (yellow) signal on release PRs whose pin is not published yet at the cost of a noisier status.
  • refresh-lockfile waits for both publishes but requires neither on its own: it runs when at least one succeeded, and each registry's steps are guarded on that registry's publish. So a crates.io failure yields an npm-only PR, an npm failure yields a Ruby-only PR (previously the job required npm success, which would have left the Ruby lock stale), and only when both fail is the job skipped. Whichever lockfile is missing from the PR still has to be refreshed by hand (rake version_check prints the cargo command; the npm one is npm install --package-lock-only --ignore-scripts). The alternative, one job per registry, would open two follow-up PRs per release.
  • Two windows carry a pin the standalone lock cannot match, and they are handled differently. Before publication, on the release-bump PR, the lock is intentionally stale and no cargo update can fix it; the ruby-platform-gem reorder above and ruby-standalone-pin's 404 skip keep CI green, and a local unpatched rake version_check is the only thing that still aborts (run rake cargo:patch_workspace first, as CI now does). After publication, between crates-publish succeeding and the refresh PR being merged, main carries a published pin with a stale lock: there ruby-standalone-pin is legitimately red on any Ruby-touching push or PR and an unpatched local rake test aborts at version_check. That is accurate signal and it heals when the refresh PR merges (the refresh PR itself is green), but it means merging that PR promptly matters. If a quieter window is preferred, the fetch step could be made non-blocking on pull_request events while the tag's refresh PR is open.
  • Adjacent, not fixed here: the Ruby release path already carries two per-release manual edits that scripts/bump-version.sh does not make — sdk/ruby/lib/microsandbox/version.rb (the script touches no sdk/ruby path by name; the extension's Cargo.toml is only reached by its generic find ... sdk -name Cargo.toml sweep) and the hardcoded gem version in ruby-source-gem's smoke assertion, which chore(release): bump microsandbox to 0.6.15 #1449 had to fix in a follow-up commit. Folding both into the bump script would be a worthwhile separate change; this PR deliberately adds no third manual step, since the lock refresh is automated in release.yml.

Test Plan

• cd sdk/ruby/ext/microsandbox && cargo update -p microsandbox --precise 0.6.15 with no patch active: all microsandbox-* entries and the lock's own microsandbox-ruby entry 0.6.14 -> 0.6.15, plus the windows-sys edge microsandbox-metrics 0.6.15 adds. (The original 0.6.9 -> 0.6.14 refresh moved msb_krun* 0.1.31 -> 0.1.32 the same way.)

• cargo fetch --locked and cargo metadata --locked in sdk/ruby/ext/microsandbox: pass on the refreshed lock; fail on the previous lock with cannot update the lock file ... because --locked was passed.

• cargo check --locked (default features): fails from a registry checkout because microsandbox-filesystem build.rs cannot find build/agentd (pre-existing, see above); passes in 10m45s with the agentd-aarch64 binary staged where that build script looks. cargo check --locked --features microsandbox_core/prebuilt passes in 14m41s.

• cd sdk/ruby && rake version_check: passes on the refreshed lock; with the lock's microsandbox entry edited to an older release it aborts with:

  Ruby/standalone Cargo.lock resolves crates.io microsandbox 0.6.14 but Cargo.toml pins 0.6.15; run `cargo update -p microsandbox --precise 0.6.15` in ext/microsandbox (with no [patch.crates-io] active) and commit the lock
  

  With the exact microsandbox block renamed (all microsandbox-* siblings intact) it aborts with:

  Ruby/standalone Cargo.lock has no [[package]] entry named microsandbox, so it was not resolved from ext/microsandbox/Cargo.toml; run `cargo update -p microsandbox --precise 0.6.15` in ext/microsandbox (with no [patch.crates-io] active) and commit the lock
  

• Release-bump rehearsal for the ruby-platform-gem reorder: scripts/bump-version.sh 0.6.16 plus the manual version.rb bump the real release PRs carry, leaving the standalone lock on 0.6.15. The old order (rake version_check) aborts naming a --precise 0.6.16 that cannot resolve, exit 1. The new order (rake cargo:patch_workspace version_check) exits 0, because patch_workspace has moved the lock aside. With version.rb desynced to 0.6.99 the reordered check still aborts with Ruby/Cargo package version mismatch, so the lockstep guard on the patch swap survives the reorder. rake cargo:unpatch_workspace restores the committed lock byte-identically.

• rake cargo:patch_workspace && rake version_check && rake cargo:unpatch_workspace on an unbumped tree: version_check passes with the lock moved aside and with a path-only lock copied in; after unpatch the committed lock is byte-identical.

• cd sdk/ruby && rake test with MSB_RUBY_INTEGRATION unset (agentd staged as above), run against the 0.6.14 pin before the merge from main: the extension compiles against the registry crates; 17 tests, 13 assertions, 0 failures, 0 errors, 7 omissions (integration tests omitted without a virtualization host). Not re-run at 0.6.15; version_check and cargo fetch --locked were.

• The pin probe against crates.io: 0.6.15 -> 200, 0.6.99 -> 404, no User-Agent -> 403.

• ruby -ryaml -e 'YAML.load_file(".github/workflows/check.yml"); YAML.load_file(".github/workflows/release.yml")' passes; actionlint is not installed locally.

• No Rust source changed; cargo fmt --check and clippy are unaffected.

Generated with Claude Code

https://claude.ai/code/session_01RqjuPiGZ34s5CPfayN8JN4

[greptile-apps]

_{Reviews (2): Last reviewed commit: "ci(release): refresh the ruby extension ..." | Re-trigger Greptile}

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 93e0db7177

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 53eee67775

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[greptile-apps]

_{Reviews (3): Last reviewed commit: "Merge branch 'main' into ruby-standalone..." | Re-trigger Greptile}

[greptile-apps]

_{Reviews (4): Last reviewed commit: "ci(ruby): patch the workspace before the..." | Re-trigger Greptile}