[gonzalo-zenrows]

Merge after #114, which adds the changelog section this PR's changelog lines use.

This PR adds an opt-in variable, ZENROWS_FETCH_RETRIES, for scrape and extract. The default is 0, so every tool call behaves as today: one request, the same output, the same errors.

With ZENROWS_FETCH_RETRIES set

1. scrape and extract retry, up to that many times, a 429, 502, 503 or 504, and a connection that failed before the request was sent (refused, name resolution, unreachable network or host, connect timeout). Every other status or error is returned at once.
2. Each wait is a Retry-After in whole seconds (clamped to 250 ms - 30 s), or else full jitter between 250 ms and min(30 s, 1 s x 2^n).
3. A retry starts only if its wait ends within 50 s of the first request, because MCP clients cancel a tool call at about 60 s. A running attempt is not cut short, so a retry that starts near 50 s can still run past the client's timeout.
4. Over stdio, a cancelled or timed-out call stops waiting and sends no more retries.
5. Each retry writes one line to stderr. The value is read once at start; an invalid one stops the server.
6. The hosted server retries only if its operator sets the variable. Crawl, batch and prepare tools are unchanged.

Tests

1. With the variable unset, a 503 through a real MCP client is sent once for scrape and for extract, and logs nothing.
2. One test per rule: the shared Retry-After and jitter vectors, which statuses and errors retry, the 50 s rule, cancel, the stderr line, and an invalid value stopping both entry points.
3. build, check:server-json, typecheck, lint and npm test pass; prettier --check passes on the touched files.

BEGIN_COMMIT_OVERRIDE
feat(fetch): new ZENROWS_FETCH_RETRIES option lets scrape and extract retry calls the API did not serve; off by default
END_COMMIT_OVERRIDE

[gonzalo-zenrows]

Same retry policy across all clients (429/502/503/504 and pre-response connection errors; 2 retries by default; full jitter; Retry-After capped at 30 s; 90 s total budget; timeouts never retried):

• Python SDK: feat(client): follow the shared retry policy when retries are turned on zenrows-python-sdk#62
• Go SDK: feat(api): opt-in retries that follow the shared retry policy, off by default zenrows-go-sdk#43
• Node SDK: feat(client): opt-in retries that follow the shared retry policy, off by default zenrows-node-sdk#58
• CLI: feat(fetch): add --retries to fetch and extract, following the shared retry policy, off by default cli#64
• MCP: feat(fetch): let scrape and extract retry calls the API did not serve, opt-in with ZENROWS_FETCH_RETRIES #80

[jonathan-zenrows]

On stdio this is fine. On the hosted server, cancellation never reaches the retry loop.

src/http.ts:398-405 creates a new transport and server for each POST (stateless, enableJsonResponse). A client's notifications/cancelled arrives in a different POST, so it lands on another Protocol that doesn't own the request, and the handler's extra.signal never fires. On top of that, the web transport in SDK 1.32.1 doesn't read req.signal, so a client disconnect doesn't abort anything either.

Repro: a client with a 60 s tool timeout calls scrape against the hosted server while the API answers 503. The client gives up at 60 s, and the server keeps sleeping and retrying until it reaches 90 s, holding a slot and API concurrency for a client that's no longer there. The tests don't catch it because tests/fetch-retry-tool.test.ts:30 uses InMemoryTransport.

Fix in http.ts:

c.req.raw.signal.addEventListener("abort", () => transport.close(), { once: true });

Protocol._onclose aborts the controllers of every in-flight handler. Add a test over the HTTP transport. Until this lands, the README/PR text about "no request after cancel" only holds for stdio.

Related: 90 s is above the ~60 s timeout of the usual clients, and scrape/extract have no per-attempt timeout (that's from before this PR). For hosted, a budget of ~55 s would make more sense.

Small: prettier --check fails on tests/extract.test.ts. Also, an AggregateError with ETIMEDOUT (happy-eyeballs) isn't retried. That's conservative, just so it's on record.

It conflicts with main, so it needs a rebase.