[jehrr]

Retrospective, for review only. This content is ALREADY on main as
9dbf278 — I pushed it directly, which was a deviation from this repo's
own practice (PRs #2–#5 all went through review) and I should have asked.
This PR exists so the change can be read as a diff.

Its base is review-base/pre-audit-response, pinned at 0d4831b — the
tree the audit examined. Merging it does nothing to main. Close it
when the review is done, and both branches can go.

Response to the third-party audit of 0d4831b (2026-10-13).

The audit's headline finding was real, and its cause was not

It reported exit 3 on a 39-byte response and concluded availability was
unproven. Its command carried --retries 0. The load loop is
range(1, retries + 1), so zero runs no navigation at all and the engine
then judges about:blank — which is 39 bytes.

One variable changed, which is the rule for this:

command	result
--retries 0 (the audit's)	exit 3, 39 bytes, four attempts, 37 s
--retries 1	exit 0, 1,395,922 bytes, 50 rows, 100% coverage, 11 s
README command, 3 pages	exit 0, 250 rows, complete, 14 s

Two general tells, both cheap: a "refusal" returning in tens of milliseconds
is not a round trip, and 39 bytes is an empty DOM rather than anything a
server sent.

So the bug is ours and is fixed — --retries 0 is now a usage error (exit 2)
— and the site was serving throughout. A corollary the audit could not have
known: this flag is affected in 26 of 45 repos in this family.

Related: its "four requests may have increased load" is not what happened.
Four outer attempts × zero navigations each = zero requests.

What the audit did not find, because it ran one mode

Between 2026-09-17 and 2026-10-13 OpenSea stopped inlining its state on the
ranking and on the activity feed; only a collection page still ships rows.
Both modes fell through to the DOM fallback — an address and a name, every
price null — and reported complete, exit 0:

mode	before	after
collections	23 rows, dom	161, graphql
activity	24 rows, dom	300, graphql
items	250	250 (unaffected)

data_source read dom on every row — the column working exactly as
designed — and nothing acted on it.

Three changes come out of that, and the third is how it reached a release:

• page 1's rows are used only when the page actually inlined some, so a
  mode that stops inlining is handled by the path that already existed for a
  request the page does not answer: the feed starts from the endpoint;
• a run that is nonetheless all-fallback says so and is no longer complete;
• all three canary jobs assert the route mix. The items job already did
  and would have gone red the next morning; the other two did not.

A claim of mine that rotted, corrected rather than dropped

The price-boundary stop rested on passing a null-sort-key cursor back
answering Something went wrong (measured 2026-09-17). Today that cursor
pages normally — a walk went 1,000 rows deep, pages 4 to 10 carrying zero
priced items. OpenSea fixed their end.

The behaviour is unchanged, because a floor scrape should still stop where
the prices stop, but it is now keyed on a page with no priced row — a
property of the catalogue rather than of the transport. Every copy of the old
sentence in the code and the docs is corrected and dated; a captured response
for both behaviours is pinned in the fixtures.

The rest of the audit's list

• P1.1, cooldown by response kind — a throttle is no longer a block.
  429/503 get their own budget (separate from --retries), honour
  Retry-After — the in-page fetch had to start returning that header, or
  honouring it was dead code — and wait at the same exit. No throttle
  has ever been seen here: x-ratelimit-remaining reads 399 and did not
  move across a burst of 60 requests, so this is implemented, unexercised,
  and driven offline against a fake driver for exactly that reason.
• P1.2, canary regression signal — the route-mix assertions above.
• P1.3, endpoint fixtures — four captured responses: an invalid cursor,
  the null-key cursor, an unknown collection, a schema validation error. All
  four come back HTTP 200, so a caller branching on the status alone
  reads every one as success. Captured, not assembled.
• P2.4, launch errors — a browser that will not start is exit 2 with one
  actionable line; --verbose re-raises the driver's own stack.
• P2.6, resume — last_cursor in the sidecar, so the one fact a resume
  would need is not discarded. Not the feature itself.
• Beyond the list — Selenium with an authenticated proxy strips the
  credentials it cannot send, gets an empty document, and used to advise
  raising --delay. It now names what it did, because it knows.

What was NOT changed, and why

• No competitor comparison in the README. This repo belongs to 2Captcha;
  a README carrying Bright Data's pricing is their advertising at our
  expense. The audit's own comparison is explicitly not a benchmark — it ran
  neither service. The honest half (what this repo does not do
  operationally) is a paragraph I will add on request.
• The engine matrix stays at three. It is a deliberate design: the three
  keep each other honest, and they did today — Selenium and pyppeteer
  independently reproduced Playwright's numbers. CI already builds a venv per
  engine, requirements are already split, and pyppeteer's unmaintained state
  is already in the README.
• No shared-loop refactor (P2.5). It is a refactor whose verification is
  a live run of three engines, and it does not belong in the same change as
  edits verified by planted faults.
• No checkpoint/resume (P2.6) and no schema version marker (P3.9).
  Both are product decisions pending family-wide, not defects here.
• The urllib3/LibreSSL warning is the auditing machine's environment
  (system Python 3.9 on macOS), not a repo defect; CI tests 3.9 and passes.
  The audit says as much itself.

Verification

• 11,045 offline assertions pass, in both virtualenvs.
• Six planted faults. Each edit asserted to have changed the file, each
  run checked for the expected message. One control stayed green — that is
  a hole in the suite rather than a pass, and the check was tightened until
  it caught the fault.
• All three engines, all three modes, live. Selenium and pyppeteer reproduce
  Playwright's rows.
• CI green on 9dbf278 (waited on the run whose headSha matched).
• Canary dispatched and green from a bare GitHub runner with no secrets:
  items 350 / collections 161 / activity 300 — a second network
  independently contradicting the audit's availability conclusion.

🤖 Generated with Claude Code