Failure
Workflow tests — job test-prqlc-c / test-c — failed run on commit 8ee5a26 (main).
Diagnosis
The failing step is Post 🔧 Setup Zig — the post-job cleanup of mlugg/setup-zig@v2 (.github/workflows/test-prqlc-c.yaml:49), not any test or build step. The cleanup tries to fetch the Zig version index to prune the cache and fails on the network:
Failed to read build.zig.zon (using latest): Error: ENOENT: no such file or directory, open 'build.zig.zon'
##[error]fetch failed
The actual work all succeeded before this — zig build test reported Compiled with 0 errors and the C binding produced correct SQL output. The failure is purely in the post-step network fetch.
The triggering commit bumped actions/setup-node from 6 to 7 (#6080), but test-prqlc-c doesn't use setup-node at all — so the bump is unrelated to this failure. check-ok-to-merge failed only because it's the omnibus gate depending on test-c.
Why no fix was produced
This is a transient network blip in an upstream action's cleanup step:
fetch failed is network-level, in a post-cleanup fetch to the Zig version index — not anything the repo's code controls.- The prior
tests run on main (f9cc67a1, ~8h earlier) passed with identical workflow config.
- The unrelated triggering commit rules out a code regression.
No repo change is warranted for a single occurrence. If this fetch failed shape from Post Setup Zig recurs across multiple runs within a week, the durable mitigation would be to make the setup-zig cache prune tolerant of fetch failures (e.g. pin the Zig version so the post step doesn't need the index, or disable use-cache on this leg).
Closing as diagnosed — no action needed.
Failure
Workflow
tests— jobtest-prqlc-c / test-c— failed run on commit8ee5a26(main).Diagnosis
The failing step is
Post 🔧 Setup Zig— the post-job cleanup ofmlugg/setup-zig@v2(.github/workflows/test-prqlc-c.yaml:49), not any test or build step. The cleanup tries to fetch the Zig version index to prune the cache and fails on the network:The actual work all succeeded before this —
zig build testreportedCompiled with 0 errorsand the C binding produced correct SQL output. The failure is purely in the post-step network fetch.The triggering commit bumped
actions/setup-nodefrom 6 to 7 (#6080), buttest-prqlc-cdoesn't usesetup-nodeat all — so the bump is unrelated to this failure.check-ok-to-mergefailed only because it's the omnibus gate depending ontest-c.Why no fix was produced
This is a transient network blip in an upstream action's cleanup step:
fetch failedis network-level, in a post-cleanup fetch to the Zig version index — not anything the repo's code controls.testsrun on main (f9cc67a1, ~8h earlier) passed with identical workflow config.No repo change is warranted for a single occurrence. If this
fetch failedshape fromPost Setup Zigrecurs across multiple runs within a week, the durable mitigation would be to make the setup-zig cache prune tolerant of fetch failures (e.g. pin the Zig version so the post step doesn't need the index, or disableuse-cacheon this leg).Closing as diagnosed — no action needed.