111+ repos pin an ORPHANED dtolnay/rust-toolchain SHA — no ref contains it, so no lockfile can be generated

[hyperpolymath]

Fourth CI fault: 111+ repos pin an orphaned action SHA, which makes a lockfile impossible

Found while remediating the estate for Workflow Dependency Locking (#657). Five of the first 34 repos swept failed at the same point, with the same cause.

The error

1 action could not be resolved — 2 workflows affected
  dtolnay/rust-toolchain@4be9e76fd7c4901c61fb841f559994984270fce7
  no tag or branch contains this commit — a symbolic ref is required for the lockfile

gh actions-lock cannot emit an entry for a commit that no ref points at, so no lockfile can be produced for the repo at all — and without a lockfile, every workflow that needs one stays dead. One unresolvable pin bricks the whole repo.

Measured

commit 4be9e76f…	exists upstream, dated 2025-12-16 — but orphaned (force-pushed off its branch)
tags dtolnay/rust-toolchain publishes	exactly one: v1 → 6c977a6ca407…
repos pinning the orphaned SHA	111 (code-search floor — it undercounts, see #668)

Known-affected so far: jtv-lang, coord-tui, social-media-tools, KnotTheory.jl, presswerk.

⚠️ Why SHA-pinning made this worse, not better

The estate pinned actions to full SHAs for supply-chain safety — correct in principle. But a SHA is only durable if a ref keeps it alive. When upstream force-pushes, the commit survives (GitHub keeps unreferenced objects) and workflows kept working, so nothing surfaced. The pin only became fatal when lockfile generation started demanding a symbolic ref.

So this failure was latent for eight months and was triggered by a GitHub feature rollout, not by any change here.

The fix

Repin dtolnay/rust-toolchain@4be9e76f… → @6c977a6ca407… (the v1 tag), estate-wide.

Generalised, this wants a check nobody has: for every pinned action SHA, assert some tag or branch contains it. That is exactly what gh actions-lock does internally, so the detector already exists — it just needs running as a gate rather than discovered during remediation.

Suggested deliverables

1. Repin the 111+ references to the v1 SHA (mechanical).
2. A sweep for other orphaned pins — this is unlikely to be the only one; prior estate audits found unresolvable pins in bulk.
3. A hypatia rule or CI gate: pinned SHA must be reachable from a ref. Cheap to implement, and it would have caught this before the rollout made it fatal.

Related: #657 (the three faults this is the fourth of), #668 (why the 111 is a floor).

[hyperpolymath]

A third dead pin found — and the pattern is now clear enough to name

Remediation has surfaced three unresolvable action pins, in two distinct classes. Both make lockfile generation impossible, so both brick a repo under Workflow Dependency Locking.

action	pinned SHA	class	live check	remapped to
dtolnay/rust-toolchain	4be9e76f…	orphaned	commit exists (2025-12-16), no ref contains it	v1 → 6c977a6ca407…
trufflesecurity/trufflehog	8a8ef852…	phantom	HTTP 422 — "No commit found"	v3.97.1 → 20652fbbdeff…
github/codeql-action	29b1f65c…	phantom	HTTP 422 — "No commit found"	v4.37.9 → cdf488f595d8…

Estate reach (code-search floors — it undercounts, see #668): rust-toolchain 111+, codeql-action 17+.

The two classes are worth distinguishing

• Orphaned — the commit is real but unreferenced, usually because upstream force-pushed. Workflows kept running, because a pin resolves an object whether or not a ref points at it. Only lockfile generation, which demands a symbolic ref, exposes it.
• Phantom — the SHA has never corresponded to any commit in that repository. github/codeql-action@29b1f65c returns 422. These pins have been sitting in workflows doing nothing verifiable at all.

The phantom class is the more troubling. SHA-pinning exists to make a supply chain checkable; a phantom pin provides the appearance of that guarantee with none of the substance, and nothing in the estate was checking.

Verified fix

All three are now remapped in the remediation script. coord-tui, which had resisted two passes, cleared immediately on the codeql remap:

coord-tui	OK	files=6

The gate this argues for, restated

For every pinned action SHA, assert some tag or branch contains it. That single check catches both classes and would have caught all three months before a GitHub rollout made them fatal. gh actions-lock already implements the logic internally — it just needs running as a gate rather than discovered during an outage.

Related: #657, #668.