A retry wrapper builds one Request object for a POST and passes that same object to fetch() on every attempt. The first attempt fails and the retry throws a TypeError before any network activity happens. What is wrong, and how do you write the wrapper correctly?

## A Request is a value that owns a body It is natural to read `new Request(url, init)` as a description of a call — a bundle of URL, method, headers and payload that you could hand to `fetch()` as often as you like. That reading is wrong in exactly one respect, and it is the respect that breaks retries. `Request` includes the same body machinery as `Response`. It has `bodyUsed`, it has `body` as a `ReadableStream`, and it has the reading methods `text()`, `json()`, `arrayBuffer()`, `blob()` and `formData()`. The body is a single-pass source. Anything that consumes it — including handing the request to `fetch()` — disturbs it permanently. ```js const request = new Request('/api/orders', { method: 'POST', headers: { 'Content-Type': 'application/json' }, body: JSON.stringify({ sku: 'A-19' }) }); await fetch(request); // body drained console.log(request.bodyUsed); // true await fetch(request); // TypeError, thrown synchronously-ish, no network ``` The second failure is not a network error and never reaches the server. That is the tell: a retry that fails instantly, with no entry in the network panel, is a client-side body-disturbance bug, not an outage. ## Why the platform does it this way A body can be a `ReadableStream` — an upload being produced as it goes, or piped from another source. There is no general way to rewind such a thing, so the Fetch Standard does not pretend some bodies are replayable and others are not. It gives every body the same one-shot rule, and provides `clone()` as the explicit opt-in for the cases where teeing is possible and wanted. ## Fix one: clone before the first send ```js async function retry(request, attempts) { let lastError; for (let i = 0; i < attempts; i++) { try { return await fetch(request.clone()); // original stays pristine } catch (error) { lastError = error; } } throw lastError; } ``` The crucial detail is that the *original* is never handed to `fetch()` — only clones are. If you send the original first and then try to clone for attempt two, `clone()` throws, because it also demands an undisturbed body. Cloning is not a repair for a spent request; it is a precaution taken while the request is still intact. ## Fix two: build a fresh Request per attempt For a retry wrapper this is the better shape. Keep the ingredients, not the object: ```js async function retry(url, init, attempts) { let lastError; for (let i = 0; i < attempts; i++) { try { return await fetch(url, { ...init, signal: AbortSignal.timeout(5000) }); } catch (error) { lastError = error; } } throw lastError; } ``` Each attempt gets its own body, built fresh from the same immutable string or `Blob`, so disturbance never enters the picture. It also gives each attempt its own signal, which matters because a signal baked into a `Request` is shared by every send derived from it — an abort or timeout that fired on attempt one would still be in the aborted state for attempt two. Constructing a `Request` is cheap and performs no network work, so there is nothing to optimise by reusing one. ## Bodies that cannot be replayed at all If the body is a `ReadableStream`, no strategy recovers it: the bytes were produced once and are gone. A wrapper that must retry such an upload has to be given a factory that can produce a *new* stream per attempt. Streaming request bodies additionally require the `duplex: 'half'` init option, and availability across browsers remains limited and Chromium-led, so a retry design that depends on them is fragile by construction. ## What is safe to hand around Bodyless requests are unaffected. GET and HEAD cannot carry a body, `bodyUsed` never becomes `true`, and the same object can be sent repeatedly — which is why the bug only ever shows up on the mutating paths. Whether those mutating requests *should* be repeated automatically is a separate question about the operation's semantics, and worth settling before the wrapper is written at all.