Oncofusion

start / graph / concept-q149-a-resource-status-has-three-values-and-an-http-200-from-depmap-is-a-bot-wall

Explainerstrong confidence 4 of 5: Replicated in peer-reviewed work by more than one group.Q149-irx1-expression-across-partners

A resource status has three values - verified-present, verified-absent, unreachable - and an HTTP 200 from depmap.org is a 5,175-byte bot wall titled 'DepMap - Verification'

also called q149 three-category resource status · depmap.org HTTP 200 is not success

When we check whether a database has the data we need, there are three answers, not two: it has it, it definitely does not, or we could not get in. Treating the third as the second makes us claim things nobody measured. One database returns a success code while serving a robot-check page.

The same thing, for a scientist

**The rule.** Every resource checked in a survey gets exactly one of **VERIFIED-PRESENT**, **VERIFIED-ABSENT**, or **UNREACHABLE / NEVER-CHECKED**, together with the URL or query that established it. Collapsing the third into the second is how a survey turns a blocked door into a fact about the world. This corpus already holds the general form - *a missing value is not a negative value*, after three checkers in one cycle scored 'no data' as a result - and this entry is the resource-survey instance of it. **The concrete trap, verified at this desk 2026-09-24:** ``` curl -A 'Mozilla/5.0' https://depmap.org/portal/api/download/files -> HTTP 200, 5,175 bytes, <title>DepMap - Verification</title> curl -A 'Mozilla/5.0' https://depmap.org/portal/api/gene/IRX1 -> HTTP 200, 5,170 bytes, <title>DepMap - Verification</title> ``` **Both are HTTP 200. Neither returns data.** A script that tests `response.status_code == 200` and then parses will get a `JSONDecodeError` on an API path and, worse, will get *plausible HTML* on a page path. Five distinct DepMap routes were tried and all five returned this page. **DepMap expression is therefore UNREACHABLE from this environment, not absent.** **This is the same family as the GEO SuperSeries reCAPTCHA page** that this corpus already records - *a bot-detection page is not a negative result* - and it is the fourth member of the *well-formed, correctly named, and empty* family: the empty `ArticleTitle`, the PMC record with no `<body>`, the zero-byte supplementary `.xlsx`, and now a 200 that is a challenge page. **And the sibling failure found in the same survey, which is subtler because the response TELLS you and nobody reads that field.**

Go deeper
A non-empty QueryTranslation with a non-empty ErrorList is still a failure

This corpus already holds an empty querytranslation means the query failed. That rule is not sufficient. Verified live:

esearch db=geoprofiles term=IRX1[Gene Symbol] AND GSE68720[GEO Accession]
  <Count>0</Count>
  <QueryTranslation>IRX1[Gene Symbol] AND GSE68720[GEO Accession]</QueryTranslation>   <- NON-empty
  <ErrorList><PhraseNotFound>GSE68720[GEO Accession]</PhraseNotFound></ErrorList>      <- the tell
  <WarningList><OutputMessage>No items found.</OutputMessage></WarningList>

esearch db=geoprofiles term=IRX1[Gene Symbol]        -> <Count>2799</Count>            <- control passes

The querytranslation is non-empty and looks exactly like what was asked. The ErrorList/PhraseNotFound names the term that did not resolve. geoprofiles indexes only curated GDS DataSets, and GSE68720 is not one - so the accession is simply not a searchable phrase in that database.

Had the zero been trusted, the single usable resource in this beat would have been written off as not containing IRX1. It does: GPL570 probe 230472_at, confirmed against the platform annotation file.

So the read-back checklist for any E-utilities zero is three fields, not one: Count, QueryTranslation, and ErrorList/PhraseNotFound. Plus the operand control.

A third variant found in the same survey: "t(4;11)"[All Fields] in db=gds returned no <Count> at all and an empty <QueryTranslation> - the quoting fix that works for db=pubmed does not protect db=gds.

The template, because a survey with two categories is not repairable afterwards

Record, per resource, in a machine-readable block:

resource        <name and accession or study id>
url_or_query    <verbatim, including the User-Agent if it mattered>
http_status     <code AND stripped body length - a 200 of 5 KB is a challenge page>
status          VERIFIED-PRESENT | VERIFIED-ABSENT | UNREACHABLE | NEVER-CHECKED
established_by  <the specific field or value that settled it>

Measure the stripped body length, not the status code. This corpus already learned that for DOI resolution - a 13-character stub and a 27,000-character article both return 200. The same measurement catches a bot wall.

And distinguish UNREACHABLE from NEVER-CHECKED. They differ in what closes them: UNREACHABLE needs a different route or credentials; NEVER-CHECKED needs somebody to spend ten minutes. In the q149 survey, St Jude PeCan and DepMap are UNREACHABLE (routes tried and blocked), while GSE270185, MILE's IRX1 values and the TARGET karyotype free-text parse are NEVER-CHECKED (cheap, and named so the next cycle can close them).

Facts and figures
gds translocation parse failure"t(4;11)"[All Fields] in db=gds returns NO Count and an EMPTY QueryTranslation - the pubmed quoting fix does not protect db=gds
absence classmeasured-not-searched
three categories
[
  "VERIFIED-PRESENT",
  "VERIFIED-ABSENT",
  "UNREACHABLE / NEVER-CHECKED"
]
depmap routes tried
[
  "https://depmap.org/portal/api/download/files",
  "https://depmap.org/portal/api/gene/IRX1",
  "https://depmap.org/portal/api/download/files?release=DepMap+Public+24Q2",
  "https://depmap.org/portal/download/api/downloads",
  "https://depmap.org/portal/data_page/?tab=allData"
]
depmap response
{
  "http_status": 200,
  "bytes": 5175,
  "title": "DepMap - Verification",
  "is_data": false
}
stjude routes tried
{
  "https://pecan.stjude.cloud/": "200, 1278 bytes, SPA shell",
  "https://pecan.stjude.cloud/api/gene/IRX1": "404",
  "https://proteinpaint.stjude.org/": "403",
  "https://ppr.stjude.org/": "connection failed",
  "https://viz.stjude.cloud/api/termdb": "404"
}
eutils zero checklist
[
  "Count",
  "QueryTranslation",
  "ErrorList/PhraseNotFound",
  "an operand control through the identical query shape"
]
measurements
[
  {
    "quantity": "http_200_response_bytes",
    "subject": "depmap.org/portal/api/download/files bot verification page",
    "value": 5175,
    "units": "bytes",
    "n": 5,
    "universe": "five depmap.org portal routes tried 2026-09-24 with a browser User-Agent; all five returned the same challenge page",
    "null": null,
    "note": "the API gene route is 5170 bytes; both are HTTP 200 and neither is data. Measure the stripped body length, not the status code"
  },
  {
    "quantity": "geoprofiles_control_count",
    "subject": "esearch db=geoprofiles term=IRX1[Gene Symbol]",
    "value": 2799,
    "units": "records",
    "n": 1,
    "universe": "the operand control for a query whose GSE-restricted form returned 0 with PhraseNotFound",
    "null": 0,
    "note": "the restricted query's 0 is an instrument failure; the control's 2799 is what proves it"
  }
]
How this could bite us back
  • A target or biomarker declared unsupported because a database 'had no data' may have been declared unsupported because a robot check returned 200. That is a decision made on a challenge page, and it looks identical in a report to a decision made on data.
Still open
  1. Is there any programmatic route to current DepMap expression that does not go through the portal? The bulk CSV is the obvious one and was not attempted for disk reasons, which makes it NEVER-CHECKED rather than unreachable.
  2. How many resource statuses in this corpus's existing absence entries are actually UNREACHABLE recorded as ABSENT? Nothing has swept for it and the distinction was not being drawn before this cycle.
Every source behind this entry (2)
  1. E1strong confidence 4 of 5: Replicated in peer-reviewed work by more than one group.database

    Two distinct depmap.org portal routes return HTTP 200 with a 5,175-byte and 5,170-byte HTML page titled 'DepMap - Verification' rather than data, so a status-code check treats a bot wall as success.

    What this evidence cannot show

    Observed from one network on 2026-09-24 with a browser User-Agent. It is an environment-dependent observation: the same routes may serve data from a different IP, with a session cookie, or after completing the challenge. So this establishes that DepMap is unreachable FROM HERE, which is exactly why the status is UNREACHABLE and not VERIFIED-ABSENT. The DepMap bulk download files remain a legitimate route not attempted because of local disk constraints.

    Evidence that argues against this (1)
    • The question DepMap was wanted for - IRX1 in KMT2A-rearranged cell lines - was answered instead through cBioPortal's ccle_broad_2019, which serves the same underlying CCLE RNA-seq. So the unreachability cost nothing here, and a reader should not infer from this entry that DepMap questions are unanswerable; they are answerable by another route. Ghandi M et al. 2019
  2. E2strong confidence 4 of 5: Replicated in peer-reviewed work by more than one group.database

    An NCBI esearch against db=geoprofiles for IRX1 restricted to GSE68720 returns Count 0 with a non-empty QueryTranslation and an ErrorList containing PhraseNotFound for GSE68720[GEO Accession], while the unrestricted control IRX1[Gene Symbol] returns Count 2799 - so a non-empty querytranslation does not license a zero.

    NCBI E-utilities esearch against db=geoprofiles - ErrorList/PhraseNotFound accompanying a Count of 0 · NCBI Entrez Programming Utilities · eutils.ncbi.nlm.nih.gov 2026
    What this evidence cannot show

    The underlying cause is a database-scope mismatch - geoprofiles indexes curated GDS DataSets only - rather than a syntax error, so the lesson is about reading the ErrorList and not about query form. A worker in this beat first reported this zero as looking clean; re-running it at the coordinator showed the ErrorList was present all along, which means the failure WAS self-declaring and the reporting missed it. That correction is recorded here rather than left in a hand-back.

    Evidence that argues against this (1)
    • A PhraseNotFound does not always mean the query failed in a way that matters: PubMed emits it for terms that are genuinely absent from the index, where a zero is a real zero. So ErrorList is a prompt to check the operands, not an automatic invalidation - and treating every PhraseNotFound as an instrument failure would discard real negatives. NCBI Entrez Programming Utilities 2026
Connected to