Skip pathwayDownloadTest when Reactome answers 200 with an error body - #2081
Merged
Merged
Conversation
Reactome's legacy BioPAX exporter has been failing on its side since somewhere after 2026-09-08 (the last green master run): every pathway id, Level2 and Level3 alike, returns HTTP 200, Content-Type text/plain Error in biopax exporter: No operations allowed after connection closed. which is a dead database connection in their backend, not a VCell change. Because it comes back as 200 rather than 5xx, the outage-skip contract added in 2c7def7 / b44f4c0 could not see it: statusOrSkip passed the status through, and the next line — assertTrue(startsWith("<?xml")) — failed the build. PathwaySearchTest carries the Fast tag, so this sits in the required CI-Test-group-Fast check and currently blocks every PR in the repo (it is what turned #2080 red; that branch does not touch pathway code). The body therefore has to decide what the status line cannot. At this endpoint a response that is not XML is their failure: a request of ours that was wrong comes back 404, which still fails. Nothing else is relaxed — the parse, xml:base, namespace, owl:imports and bp:pathway assertions are untouched. Verified against a local server through the real helpers, with the checked-in insulinPathway-5683177.xml fixture as the good response: 200 + BioPAX XML passes all assertions, 200 + the plain-text error skips, 404 fails, and 200 + well-formed but wrong XML still fails on "Missing xml:base". Against the live services the class now reports 3 run, 2 skipped, 0 failures (PathwayCommons /pc2/search is also timing out today, which the existing guard already handled). Note the same endpoint backs the desktop client's Reactome import (BioModelEditorPathwayCommonsPanel.java:386), so that feature is broken for users while Reactome is in this state. Tracking that separately — this commit only stops a third party's outage from failing our build. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01D71LBYmQNf5J94wPqr81Jx
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What is failing
PathwaySearchTest.pathwayDownloadTestfails on every branch right now, including#2080's run, which does not touch pathway code:
Why
Reactome's legacy BioPAX exporter is broken on their side — every pathway id, Level2 and Level3:
That is a dead database connection in their backend, reported as 200 instead of 5xx, so the
outage-skip contract from 2c7def7 / b44f4c0 cannot see it:
statusOrSkippasses the statusthrough and the content assertion on the next line fails the build. Master was last green on
2026-09-08, so this broke sometime after that.
The test carries the
Fasttag, so it is in the requiredCI-Test-group-Fastcheck — whileReactome stays in this state, no PR in the repo can merge without an admin override.
The change
The body decides what the status line cannot: at this endpoint a response that is not XML is
their failure, because a request of ours that was wrong comes back 404 and still fails.
Nothing else is relaxed — the parse,
xml:base, namespace,owl:importsandbp:pathwayassertions are untouched.
Verification
Against a local server through the real helpers, using the checked-in
insulinPathway-5683177.xmlfixture as the good response:Unexpected HTTP status)Missing xml:base)Against the live services the class now reports 3 run, 2 skipped, 0 failures — PathwayCommons
/pc2/searchis also timing out today, which the existing guard already handled.Separately worth knowing
The same broken endpoint backs the desktop client's Reactome import
(
vcell-client/src/main/java/cbit/vcell/client/desktop/biomodel/BioModelEditorPathwayCommonsPanel.java:386),so that feature is currently broken for users. Reactome's newer ContentService has no drop-in
BioPAX replacement (
/ContentService/exporter/event/{id}.biopax2→ 404), so this needs its owndecision; this PR only stops a third party's outage from failing our build.
🤖 Generated with Claude Code
https://claude.ai/code/session_01D71LBYmQNf5J94wPqr81Jx