rust-ci-reusable.yml @cc5a372 fails with zero jobs on every estate caller — investigation findings

[hyperpolymath]

Symptom

Every estate repo wrapping rust-ci-reusable.yml@cc5a372af1af1b202c17f1b21efd954e6c038bef completes its run as failure with zero jobs created (not zero passing — literally no jobs in the run). Pattern is universal:

Repo	rust-ci.yml runs	success ratio
echidna	100 (last 100)	0 / 100
ephapax	sampled	0 / 3
conflow	sampled	0 / 3
zerostep	sampled	0 / 3
neurophone	sampled	0 / 5 (last success: 2026-05-14 inline format, before wrapper conversion)

14 repos confirmed pinning the same SHA via gh search code — no repo has repinned to a newer rust-ci-reusable.yml commit.

What's confirmed NOT the cause

• ✅ Caller wrapper YAML parses (verified with python3 -c 'import yaml; yaml.safe_load(open(".github/workflows/rust-ci.yml"))').
• ✅ The pinned SHA cc5a372 is an ancestor of standards/main (verified with git merge-base --is-ancestor).
• ✅ The reusable file exists at that SHA and parses (verified via Contents API + python yaml).
• ✅ All inputs: in the reusable have defaults; the wrapper provides valid bool values for enable_audit / enable_coverage.
• ✅ All actions referenced inside the reusable resolve to real commit SHAs (no fakes).
• ✅ No required-status checks on echidna's ruleset blocking the workflow from running (it just runs and instantly fails).

What's potentially suspicious

1. referenced_workflows: [] on every failure run (via REST API), suggesting GitHub's workflow_call dispatcher never resolved the reusable to a job graph.
2. Run completes in 0 seconds (created_at == updated_at) — dispatcher rejects before any runner is provisioned.
3. Workflow display name fell back to file path (.github/workflows/rust-ci.yml) instead of the file's name: Rust CI — this is sticky from the original workflow registration, not load-bearing here but a parser-strictness signal.
4. Standards does not dogfood its own reusable — there's no caller of rust-ci-reusable.yml inside hyperpolymath/standards, so the reusable hasn't been runtime-validated since feat(governance): add rust-ci-reusable + elixir-ci-reusable workflows #174 introduced it.
5. Two actions inside the reusable (dtolnay/rust-toolchain@4be9e76f, codecov/codecov-action@ab904c41) are pinned to diverged SHAs (not ancestors of their respective default branches). This would normally fail at step-execution time, not at workflow-call time, but might trigger different behaviour depending on how strictly GitHub validates child actions during dispatch.

What's been tried

• Repinned to live SHA (PR docs(licence-policy): A5 — scaffold-placeholder leak is NOT licence debt #140 in echidna et al.) — already at cc5a372 which is the latest reachable commit.
• Verified action SHAs inside the reusable — all real commits.
• Cross-checked log retrieval — /logs endpoint returns 404 (no logs to retrieve, no jobs ran).

Possible next steps (owner-decision)

1. Bump pin estate-wide to 822fa14 (latest reusable commit, post-ci(rust-ci-reusable): pass --locked to cargo check/clippy/test (closes #295) #299 --locked change). If the dispatcher rejection is content-dependent, the newer version might just work. Cheap to test on one repo first.
2. Add dogfood self-test in standards: a caller workflow that uses rust-ci-reusable.yml@${{ github.sha }} so PR CI in standards catches dispatcher rejections at PR time.
3. Repin internal-action SHAs (dtolnay/rust-toolchain, codecov/codecov-action) to ancestor-of-default-branch SHAs and republish the reusable. Mirrors the orphan-SHA pattern PR docs(licence-policy): A5 — scaffold-placeholder leak is NOT licence debt #140 fixed for top-level wrappers.
4. Capture a GitHub support diagnostic — for a known-good caller and a known-bad caller of the same reusable. Would clarify whether this is a GitHub-side or repo-side issue.

This issue exists for visibility — the failure has been silent (zero jobs ⇒ no annotations ⇒ no obvious red-screen UI). Owner direction welcomed on which path to take.

Estate-wide impact

CI gate that should run on every Rust PR estate-wide has been red since wrapper conversion (~2 weeks). Currently flagged as failure on every push to main. Per the cross-PR check pattern this can be ignored as "red on main too" — but means rust regressions land without runtime validation.

Refs:

• echidna#140 (top-level wrapper SHA repin)
• standards#174 (reusable introduction)
• standards#295 / ci(rust-ci-reusable): pass --locked to cargo check/clippy/test (closes #295) #299 (post-cc5a372 reusable changes)

🤖 Generated with Claude Code