A transient error from the BioNetGen download turns a whole test matrix leg red before any test runs

The issue is in the GitHub Actions workflow file .github/actions/setup-pybnf. Look for the curl command that downloads the BioNetGen tarball. Add retry flags (--retry 5 --retry-delay 2 --retry-all-errors) to the curl command. Optionally, consider adding caching with actions/cache keyed on the version. Test by pushing a branch and verifying the workflow runs without network errors, and that a cache miss still succeeds.

Summary

Every job that uses .github/actions/setup-pybnf downloads the BioNetGen 2.9.3 tarball from GitHub's release endpoint with a single unretried curl. When that endpoint returns an error the step exits non-zero, the venv is never created, and the whole matrix leg goes red without running a test.

This happened on main at 92313ae5 (run 35883852931):

curl: (22) The requested URL returned error: 500
##[error]Process completed with exit code 22.

The next step, "Create venv and install pybnf", was skipped. Zero tests ran. The other three legs of the same run passed, and re-running the one job cleared it.

Why it is worth fixing rather than re-running

To be accurate about frequency: I checked the last twenty failed runs and this is the only one with this cause. The others were genuine test failures. So this is not yet a pattern, and the case does not rest on one.

It rests on the shape. The fetch is a single unretried network call sitting in the setup path of every test job, before anything else runs:

curl -fsSL \
  https://github.com/RuleWorld/bionetgen/releases/download/BioNetGen-2.9.3/BioNetGen-2.9.3-linux.tar.gz \
  -o "$RUNNER_TEMP/bionetgen.tar.gz"

Three properties make a blip expensive:

1. No retry. curl -fsSL gives up on the first response. A 500 from a third-party endpoint is exactly the failure a retry is for.
2. No cache. The uv cache is restored via astral-sh/setup-uv with a cache-suffix, but the tarball is re-downloaded by every job on every run. tests.yml alone is four jobs, plus one in docs.yml and three in integration.yml, so a normal push makes the same request five to eight times and each one is an independent chance to fail.
3. It fails red, not yellow. A setup failure is indistinguishable at a glance from a real test failure. It sends the same notification, and someone has to open the log to learn that nothing was tested.

The cost of a false red is not the re-run. It is that a red main gets discounted, which is what makes a real failure easy to walk past.

Suggested fix

Smallest version, retry in place:

curl -fsSL --retry 5 --retry-delay 2 --retry-all-errors \
  https://github.com/RuleWorld/bionetgen/releases/download/BioNetGen-2.9.3/BioNetGen-2.9.3-linux.tar.gz \
  -o "$RUNNER_TEMP/bionetgen.tar.gz"

--retry-all-errors is the part that matters, since plain --retry does not retry a 500 response by default.

Better, and worth considering together with the retry: cache the extracted tree with actions/cache keyed on the BioNetGen version, so the normal path makes no network call at all and only a cache miss reaches the endpoint. The version is pinned in the URL already, so the key is stable and never needs invalidating.

Either way the version should be lifted into one place rather than being spelled twice in the URL and once in the BNGPATH line, so a future bump cannot leave them disagreeing.

Verification

Hard to test directly without faking the endpoint. The honest check is that a cache hit produces no request in the log and that a forced miss still installs correctly, which a single run on a branch demonstrates.