estate-wide rust-ci.yml 0s-duration parse failures on 43+ callers since 2026-05-26 (post-thin-wrapper-conversion)

[hyperpolymath]

Symptoms

`rust-ci.yml` thin-wrapper callers across the estate fail with 0s-duration "completed failure" runs on every push since 2026-05-26 (the day the thin-wrapper conversion landed via standards#174 / panic-attack#45 et al). Affects 43+ repos (full list via `gh search code --owner hyperpolymath 'rust-ci-reusable.yml@'`).

Sample failed runs (panic-attack):

• 2026-05-30T23:24:11Z — branch `fix/rust-ci-repin-822fa14e` (post-822fa14e bump)
• 2026-05-30T23:04:26Z — main
• All prior runs since 2026-05-26 — failure

What's NOT the cause

1. Orphan SHA — panic-attack#84 hypothesised the original `4fdf4314` pin was orphan and repinned to `cc5a372a`. `cc5a372a` IS reachable from `standards/main` (`git merge-base --is-ancestor cc5a372 HEAD` returns true). Repinning forward to `822fa14e` (current main HEAD on the reusable) does NOT fix it either — verified via panic-attack#92 (closed).
2. YAML syntax — `python3 -c 'import yaml; yaml.safe_load(open(...))'` parses the caller cleanly.
3. Cross-repo access — standards is public, `allowed_actions: all`, `sha_pinning_required: true` (but this only affects standards' own internal actions usage, not external callers).
4. Reusable interface drift — no required inputs on the reusable; defaults provided for everything.

Smoking gun

The workflow API consistently reports the workflow's `name` field as the path (`.github/workflows/rust-ci.yml`), not the YAML `name: Rust CI`. Strong indicator that GitHub Actions has never successfully parsed the workflow definition since the thin-wrapper conversion. The path-based fallback name is what GH uses when YAML parsing fails or the workflow definition is rejected before parse completes.

Hypotheses to test

1. Caller-side workflow file structural issue — perhaps the thin wrapper missing a required field that the YAML spec allows but GH Actions rejects (e.g., needs explicit `jobs..permissions` even though the reusable declares its own).
2. Reusable-side permissions/secrets contract — even though no required inputs exist, perhaps GH expects `secrets: inherit` for cross-repo reusables in this org config.
3. Cached bad parse — workflow_id 231679368 (panic-attack) was created 2026-02-07 with the OLD self-contained workflow content. The thin-wrapper conversion REUSED the same workflow_id rather than creating a new one. GH may have cached the old parse and never re-evaluated.

Suggested next steps

• Take ONE repo and EXPERIMENTALLY: (a) delete `.github/workflows/rust-ci.yml` entirely, push, watch the workflow disappear from the Actions tab; (b) add it back as a NEW filename like `rust-ci-v2.yml`. If the new filename works, hypothesis 3 is confirmed and the fix is renaming across the estate.
• ALTERNATIVELY: try `uses: hyperpolymath/standards/.github/workflows/rust-ci-reusable.yml@main` (floating ref) on ONE repo — if floating refs sidestep the failure, the bug is in the SHA-resolution layer specifically.

Refs

• panic-attack#84 (the failed orphan-fix attempt)
• panic-attack#92 (the failed SHA-bump experiment, now closed)
• standards#174 (PR introducing the reusable)
• standards#299 (`--locked` flag, current HEAD on the file)

Out of scope here

The aggregator-gate refactor pattern (panic-attack#90 / ephapax#254) is orthogonal — rust-ci-reusable.yml is not currently in any ruleset's `required_status_checks`, so the 0s failure isn't blocking any PRs (just visually red). Fix at standards level when bandwidth allows.

🤖 Generated with Claude Code