chore(workspace): refresh Cargo.lock for stella-time after the 0.9.417 sync - #6502
chore(workspace): refresh Cargo.lock for stella-time after the 0.9.417 sync#6502macanderson wants to merge 1 commit into
Conversation
There was a problem hiding this comment.
Sorry @macanderson, you've used your own review budget of 250,000 diff characters for the last 7 days.
You can request another review in 2 days and 3 hours by commenting @sourcery-ai review. Upgrade to get a review now.
Reviewer's guide (collapsed on small PRs)Reviewer's GuideRefreshes the single File-Level Changes
Tips and commandsInteracting with Sourcery
Customizing Your ExperienceAccess your dashboard to:
Getting Help
|
|
Already on The file comparison on this PR still shows the change only because the branch was cut before #6497 merged, so the merge base predates it. Rebased onto current main the diff is empty. Three sessions independently wrote this same line within half an hour. That is worth noting on #6495 rather than in three closed PRs: the canary tells everyone at once, and nothing tells them somebody is already on it. No action needed here. |
What & why
mainis red (#6495):Cargo.locknamesstella-timeat 0.9.416 while the workspace version is 0.9.417, so every--lockedbuild fails. #6488 added the crate with a lock refreshed against the 0.9.416 sync, and the 0.9.417 sync (#6494) landed between that PR's last rebase and its merge; the merge check ran on the older merge commit. This is the #5939 shape.The fix is the one-line lock refresh (
cargo update -w):stella-time0.9.416 → 0.9.417, nothing else.Refs #6495 (the canary closes it once
mainis green again). Trivial change, closes no issue (no-issue).The witness
cargo metadata --lockedfails onmainand passes here.The gate
cargo fmt --check(no Rust touched)lockfile-syncandcompileare the checks that were redSummary by Sourcery
Bug Fixes: