#1137 moved the integration tests to a nightly run so that third-party outages stop blocking pull requests. That fixed the large case. This is the residue: several tests in biojava-structure — a unit module, run on every pull request — still reach data.rcsb.org directly.
Two examples from a single evening, 2026-08-26:
#1134 AtomCacheTest.testGetStructureForDomain2
502 for https://data.rcsb.org/rest/v1/holdings/status/1I3O
run 33010700441
#1144 PDBStatusTest.testGetCurrent
502 for https://data.rcsb.org/rest/v1/holdings/status/3HHB
run 33019289062
Both cleared on a re-run with no code change. Both times the other four matrix jobs passed against the same endpoint — so this is an intermittent 502 rather than an outage, and a five-way matrix is very good at catching those. Two unrelated pull requests, two red checks, two manual re-runs.
Why this is worth a small fix rather than a shrug
They share one call site: the holdings-status lookup in PDBStatus. Stubbing or caching that single call would take both tests offline at once, without moving whole classes to the nightly — which would hide the coupling rather than remove it.
There is also a subtler variant, found in #1145: a test can look offline and not be. CathInstallationTest feeds a StringReader to the parser, then reads the result back through getDomainByCathId, which internally downloads the real CATH domain list. It passed on Linux only because the download did not finish in time.
That is the failure mode worth naming: a network dependency hidden behind an accessor, where the test appears self-contained and its pass or failure depends on how fast a third party responds.
Proposed
- Survey which tests in the unit modules open a socket, and to which services. I am happy to do this and post the list.
- For each: stub or fixture it if it is a unit test, or move it to
biojava-integrationtest if it genuinely tests the integration.
- Consider a build-time guard so a new network call in a unit module is noticed when it is added rather than the next time the service has a bad minute.
Point 3 is the one I am least sure about — it may be more machinery than the problem deserves. Points 1 and 2 seem clearly worth doing.
Relates to #910 and #1137.
#1137 moved the integration tests to a nightly run so that third-party outages stop blocking pull requests. That fixed the large case. This is the residue: several tests in
biojava-structure— a unit module, run on every pull request — still reachdata.rcsb.orgdirectly.Two examples from a single evening, 2026-08-26:
Both cleared on a re-run with no code change. Both times the other four matrix jobs passed against the same endpoint — so this is an intermittent 502 rather than an outage, and a five-way matrix is very good at catching those. Two unrelated pull requests, two red checks, two manual re-runs.
Why this is worth a small fix rather than a shrug
They share one call site: the holdings-status lookup in
PDBStatus. Stubbing or caching that single call would take both tests offline at once, without moving whole classes to the nightly — which would hide the coupling rather than remove it.There is also a subtler variant, found in #1145: a test can look offline and not be.
CathInstallationTestfeeds aStringReaderto the parser, then reads the result back throughgetDomainByCathId, which internally downloads the real CATH domain list. It passed on Linux only because the download did not finish in time.That is the failure mode worth naming: a network dependency hidden behind an accessor, where the test appears self-contained and its pass or failure depends on how fast a third party responds.
Proposed
biojava-integrationtestif it genuinely tests the integration.Point 3 is the one I am least sure about — it may be more machinery than the problem deserves. Points 1 and 2 seem clearly worth doing.
Relates to #910 and #1137.