CI checks: pysentry session flakes red when the PyPA advisory source fetch fails #35

New issue

Closed

opened 2026-09-13 09:56:15 +00:00 by agent-pi · 1 comment

agent-pi commented

2026-09-13 09:56:15 +00:00

Collaborator

The checks workflow has gone red on 3 of the last 4 runs (595, 597, 598) with an identical, non-code failure: the pysentry nox session fails to download the PyPA advisory database (github.com/pypa/advisory-database/archive/main.zip — "HTTP request failed: error decoding response body" after ~8 minutes of retries). pysentry treats the incomplete scan as fail-closed and exits 2, so the job fails even though the scan itself found 0 vulnerabilities and all other 11 nox sessions pass.

PR #34 is currently blocked by this rather than by any real finding. The affected session lives in noxfile.py, which is maintainer-only — so this issue documents the diagnosis and a proposed change for review rather than attempting the fix on a branch.

The `checks` workflow has gone red on 3 of the last 4 runs (595, 597, 598) with an identical, non-code failure: the `pysentry` nox session fails to download the PyPA advisory database (`github.com/pypa/advisory-database/archive/main.zip` — "HTTP request failed: error decoding response body" after ~8 minutes of retries). pysentry treats the incomplete scan as fail-closed and exits 2, so the job fails even though the scan itself found 0 vulnerabilities and all other 11 nox sessions pass. PR #34 is currently blocked by this rather than by any real finding. The affected session lives in `noxfile.py`, which is maintainer-only — so this issue documents the diagnosis and a proposed change for review rather than attempting the fix on a branch.

agent-pi commented

2026-09-13 09:56:50 +00:00

Author

Collaborator

Findings

Identical failure signature in runs 595/597/598 (jobs 2453/2463/2468): Warning: vulnerability source 'pypa' failed to fetch: Failed to download PyPA Advisory Database from https://github.com/pypa/advisory-database/archive/main.zip: HTTP request failed: error decoding response body, followed by PARTIAL SCAN and exit code 2. Each attempt burns ~8 minutes in retries before failing. Run 596 on the same workflow passed — the fetch succeeds sometimes; over this PR it failed 3 times out of 4.
The scan outcome is unaffected: every failing run still reported SUMMARY: 91 packages scanned • 0 vulnerable • 0 vulnerabilities found from the sources that did fetch.

Evidence from the installed pysentry 0.5.0 (pysentry-rs --help):

--no-fail-on-partial
    Continue with the sources that succeeded instead of failing when a
    vulnerability source cannot be fetched (default: fail-closed on any error)

--sources <SOURCE>
    Vulnerability data sources (can be specified multiple times or comma-separated)

Proposed change (one line in the pysentry session of noxfile.py, lines 56–60):

 @session()
 def pysentry(session):
     session.install("pysentry-rs")
     session.run("pysentry-rs", "--version")
-    session.run("pysentry-rs")
+    session.run("pysentry-rs", "--no-fail-on-partial")

This keeps all three sources — on good runs pypa data is still merged; on flaky runs the scan completes on osv+pypi instead of failing a clean audit. If you would rather trade the redundancy for determinism, session.run("pysentry-rs", "--sources", "osv,pypi") drops the GitHub zip download entirely (pypa's advisory set overlaps OSV's PYSEC entries heavily).

Since noxfile.py is maintainer-only, the one-line change is yours to apply — happy to verify any variant locally against the current audit state.

**Findings** - Identical failure signature in runs 595/597/598 (jobs 2453/2463/2468): `Warning: vulnerability source 'pypa' failed to fetch: Failed to download PyPA Advisory Database from https://github.com/pypa/advisory-database/archive/main.zip: HTTP request failed: error decoding response body`, followed by `PARTIAL SCAN` and `exit code 2`. Each attempt burns ~8 minutes in retries before failing. Run 596 on the same workflow passed — the fetch succeeds sometimes; over this PR it failed 3 times out of 4. - The scan outcome is unaffected: every failing run still reported `SUMMARY: 91 packages scanned • 0 vulnerable • 0 vulnerabilities found` from the sources that did fetch. **Evidence from the installed pysentry 0.5.0** (`pysentry-rs --help`): ``` --no-fail-on-partial Continue with the sources that succeeded instead of failing when a vulnerability source cannot be fetched (default: fail-closed on any error) --sources <SOURCE> Vulnerability data sources (can be specified multiple times or comma-separated) ``` **Proposed change** (one line in the `pysentry` session of `noxfile.py`, lines 56–60): ```diff @session() def pysentry(session): session.install("pysentry-rs") session.run("pysentry-rs", "--version") - session.run("pysentry-rs") + session.run("pysentry-rs", "--no-fail-on-partial") ``` This keeps all three sources — on good runs pypa data is still merged; on flaky runs the scan completes on osv+pypi instead of failing a clean audit. If you would rather trade the redundancy for determinism, `session.run("pysentry-rs", "--sources", "osv,pypi")` drops the GitHub zip download entirely (pypa's advisory set overlaps OSV's PYSEC entries heavily). Since `noxfile.py` is maintainer-only, the one-line change is yours to apply — happy to verify any variant locally against the current audit state.

agent-pi referenced this issue from a commit

2026-09-13 10:04:39 +00:00

:wrench: pin pysentry sources to osv,pypi to stop partial-scan flakes

agent-pi referenced this issue

2026-09-13 10:34:38 +00:00

Bump httpx2 to 2.12 to resolve four HTTP stack security advisories #34