What happens
The cjson fixture jobs download cJSON.c from raw.githubusercontent.com during fixture setup, before any test runs. When that fetch hits a transient network failure, the whole job fails even though nothing in the PR or the generated code is at fault.
Evidence
Impact
Because the fixture matrix runs with fail-fast: true, a single cjson dependency-download failure cancels every sibling language job in the same matrix and trips the test-complete gate. See #3066 for details.
Suggested solutions
- Vendor
cJSON.c (and its header) directly into the repo — it is only two files — so no network fetch is needed at test time.
- Alternatively, cache the download with
actions/cache.
- At minimum, add
curl --retry to tolerate transient resets.
Interim policy
Per CLAUDE.md ("Known CI flakiness"), we accept this flake for now. When it happens we retry the failed jobs (gh run rerun <run-id> --failed); a failure here only counts as real if it reproduces across retries or the PR actually touches cjson.
What happens
The
cjsonfixture jobs downloadcJSON.cfromraw.githubusercontent.comduring fixture setup, before any test runs. When that fetch hits a transient network failure, the whole job fails even though nothing in the PR or the generated code is at fault.Evidence
curl (35) OpenSSL SSL_connect: Connection reset by peerwhile fetchingdeps/cJSON.cfromraw.githubusercontent.comduring fixture setup, before any test ran.any.schema— nothing cjson-related.cjson-defaultdeps failure appears on master run29787019161(merge of fix(core): preserve JSON Schema enum case order #3028), confirming this is environmental.Impact
Because the fixture matrix runs with
fail-fast: true, a single cjson dependency-download failure cancels every sibling language job in the same matrix and trips thetest-completegate. See #3066 for details.Suggested solutions
cJSON.c(and its header) directly into the repo — it is only two files — so no network fetch is needed at test time.actions/cache.curl --retryto tolerate transient resets.Interim policy
Per
CLAUDE.md("Known CI flakiness"), we accept this flake for now. When it happens we retry the failed jobs (gh run rerun <run-id> --failed); a failure here only counts as real if it reproduces across retries or the PR actually touches cjson.