[olsonanl]

Summary

Closes the last uncovered Data API transport for
CLIENT-429.md.
#1465 covered dojo/request (via the requestProvider) and P3JsonRest; bvbrc_js_client
uses fetch and saw neither.

Its failure mode was the worst of the three. The client threw
Error(response.statusText), discarding the status, so a shed request couldn't even
reach the throttle banner — the user got a broken panel and no explanation. That discard is
also precisely why this couldn't be fixed from outside the client, so httpError() is part
of the fix rather than a tidy-up.

Still gated behind enableThrottleRetry (default false). Same flag, same
/throttle/* topics, same banner.

Why this matters now

GenomeAlignment.js:128,146 queries through this client with limit: 25000 — heavy enough
to be shed under admission control, making it the most likely thing on the site to be shed
and previously the least able to cope. MSA, PhylogeneticTree, MetaCATS, ViralGenomeTree,
SeqComparison, Homology, ProteinFamilies and PathwayService use the same path at lighter
limits.

Two commits, reviewable separately

7ecacade6 — vendor the client, zero behaviour change.
public/js/bvbrc_js_client was a symlink into node_modules; git tracked the symlink
and nothing inside it. The source lived in github:bv-brc/bvbrc_js_client, pinned at
3847d9c5 — which is also HEAD of main, untouched since 2021-08-10, with no other
consumer in the org. So the client simply wasn't editable from this repo.

Bundle is byte-identical (sha256 9aed465e…), verified on disk and as served over
HTTP. views/javascript.ejs already loads it by path, so nothing in the load path moves.
Also drops a git+ssh:// dependency from the install path.

This copy is now the source of truth; upstream can be resynced later if another consumer
appears.

0ee5f8671 — the actual 429 handling.
src/retry.js: honour Retry-After, jitter up to +30%, cap at 3 retries, 429/503 only,
floor every delay at 1s. All four fetch call sites route through it.

Verified live

Injected 429s, flag on. All four transports now recover where previously three did:

429 -> 429 -> 200  gaps 3012, 4743 ms  POST genome/          (P3JsonRest)
429 -> 429 -> 200  gaps 3120, 4052 ms  genome/?select(...)   (this client)  <- was failing
429 -> 429 -> 200  gaps 3014, 5460 ms  data/taxon_category/  (provider)
429 -> 429 -> 200  gaps 3099, 11139ms  genome/?facet(...)    (provider)

200 grid rows, banner counts down and hides on recovery, and the Error: Too Many Requests
exception present in every previous run is gone.

15 mocha tests in the package; 75 jest tests in the host repo still pass.

Two traps found on the way

The build was broken, and failed destructively. node-fetch: ">=2.6.1" resolved to
3.x, which is ESM-only and unparseable by browserify. Because the build pipes through
derequire, the failure truncated dist/bvbrc_client.js to zero bytes rather than
leaving the previous bundle intact. Pinned to ^2.7.0 (CJS) and committed the lockfile so
the bundle is reproducible. Same class as the prod Node 22 ESM breakage in CLAUDE.md.

.gitignore nearly swallowed the vendored source. The bare src/ and test/ rules
(lines 21–22) are unanchored and match at any depth — the first git add staged 7 of 30
files, with dist/ but no src/. Re-included explicitly. Worth knowing before vendoring
anything else.

What reviewers should kick

src/retry.js is a deliberate duplicate of p3/util/retryRequest.js. The package is
standalone with no AMD loader, so it can't import it. Two implementations of the same
contract will drift, and I'd rather that be an explicit decision than something discovered
later. Noted in both files. If you'd prefer a different structure — build-time inlining, or
collapsing the client into a thin p3/ shim — say so.

Also unexercised beyond /view/GenomeList/: the pages that actually use this client
(Genome Alignment, MSA, trees) weren't driven under throttling, only the shared
GenomeList.js:49 call. The retry path is identical, but the consuming code is not.

Remaining gap

Downloads (§4) — form.submit() / window.open() hand the response to the browser, so
no wrapper can reach them, and they're heavy (DownloadTooltipDialog.js:106 requests
limit(2500000)). Converting to XHR+Blob is the fix and the natural first unattended
caller. Not in this PR.

🤖 Generated with Claude Code