Repository navigation
fix(lock): relock-standards-pin matches records case-insensitively on owner/repo - #1314
hyperpolymath wants to merge 1 commit into
Conversation
… owner/repo
GitHub's lockfile parser (github/actions-lockfile v0.0.6) folds owner/repo
case. 'Swatinem/rust-cache@6323deb…' and 'swatinem/rust-cache@6323deb…'
are one key to it. Two records for that key with different metadata are a
parse error ("duplicate action key ... after canonicalization with
differing metadata"), and every run that reads the lock then fails.
relock-standards-pin.sh looked records up byte-for-byte. A consumer that
held 'Swatinem/rust-cache@6323deb…' (ref v2) was treated as lacking the
record the reusables name as 'swatinem/rust-cache@6323deb…', so the script
copied standards' record (ref v2.9.2) beside it. Measured on
hyperpolymath/januskey when re-pinning 7d2041a -> 75bd599: the result
failed the parser.
The fix:
- Record lookup (and the poisoned self-SHA repair) find the consumer's
record under any owner/repo spelling and keep that spelling.
- The prune pass compares edges and records the same way.
- The closure check compares edges and records the same way.
Tests: two new cases in scripts/tests/relock-standards-pin-test.sh, a
record held under another case (kept, not duplicated) and a self-SHA
record held under another case (repaired in place). Both failed before
this change. The whole suite passes, including its check-lock-sync legs
(gawk present). shellcheck reports no new findings.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_013CuBToxr5h9catptGiTsFX
|
Warning Review limit reachedYou've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. Next included review available in 59 minutes. View limit details
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
🟢 conformant · commit
K9 live corpus (L0–L2): 2 finding(s) / scope notes
Scope: DEED syntax and K9 contracts L0–L2. L3 signature verification and routed coordination dialects are not certified. Green is limited to this scope. Orange is missing evidence; grey is an explicit scope exclusion. Logs and report.json are in the dated conformance-evidence artifact on the linked run. |
|
|
Two red checks here are not from this PR:
Both fail identically on I don't know of a fix to port. The PR's own suite passes, along with Lock Sync, Lock Self-Check and the actions-lock gate. Generated by Claude Code |
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 6de5f9248d
ℹ️ 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".
| key=$(lock_key "$u" "$tmp/lock") | ||
| existing=""; [ -z "$key" ] || existing=$(rec_body "$key" "$tmp/lock") |
There was a problem hiding this comment.
When the consumer has no matching record and the target Standards lock keys the needed action under different owner/repo casing, this case-insensitive lookup finds nothing locally, but the fallback at line 177 still calls rec_body "$u" "$tmp/slock" with exact casing. For example, a reusable edge acme/tool@<sha> with a valid source record ACME/Tool@<sha> is refused as “no record” rather than copied. Use lock_key for the normal source-lock fallback as well as for the self-SHA repair path.
Useful? React with 👍 / 👎.
|
Add Carrot credits or activate Agent usage billing to use Autofix |
This branch has not been deployed
2 participants
Summary
scripts/relock-standards-pin.shmatched lock records byte-for-byte. GitHub's lockfile parser (github/actions-lockfilev0.0.6,canonicalizeActions) folds owner/repo case.Take a consumer that holds
'Swatinem/rust-cache@6323deb…'(refv2), where the reusables at the target name the action asswatinem/rust-cache@6323deb…. The script did not see the consumer's record, so it copied standards' record (refv2.9.2) next to it. The resulting lock fails to parse:A lock that does not parse fails every run that reads it. I measured this on hyperpolymath/januskey while re-pinning
7d2041a→75bd599to fix the estate-wideinvalid lockfile pinfailure. That failure comes from standards locks before #1271 having self-SHA refs;lock-selfcheck.shreports7d2041aas POISON.What changes
How has this been verified?
scripts/tests/relock-standards-pin-test.sh:FAIL: case variant: the record is keyed 2 times). The whole suite passes after it, including itscheck-lock-sync.shlegs with gawk installed.shellcheck: 12 findings before and 12 after, all pre-existing. The change adds none.actions-lockfilev0.0.6Parse, andcheck-lock-sync.shreports it in sync.Notes for reviewers
complete-job-refs.shalready got case-insensitive dedupe in fix(lock): complete-job-refs dedupes owner/repo case-insensitively #1294. This PR bringsrelock-standards-pin.shinto line with it.propagate-workflow-pins.sh --fixand the scheduled applier both call this script, so any estate re-pin could have hit this bug.lock-selfcheckor the lock gates. It would catch a lock that does not parse before it is pushed.Generated by Claude Code