[whatwg/fetch] New Proposal: Fetch retry (Issue #1838)

rakina created an issue (whatwg/fetch#1838)

### What problem are you trying to solve?

fetch() requests can fail due to transient network errors. Manual JavaScript retries are complex and impossible to be done after page unload (e.g. for keepalive fetches), causing data loss for critical beacons.

### What solutions exist today?

Manual JavaScript Retry Logic: Developers write try...catch blocks, manage setTimeout for delays (often implementing exponential backoff), and track attempt counts.

Limitations: Requires boilerplate code, potentially complex to manage state correctly. Doesn't work for keepalive requests as the JavaScript context is unavailable to handle retries after page unload.

### How would you solve it?

Add a new retry capability for fetches, as proposed in the explainer: https://github.com/explainers-by-googlers/fetch-retry/blob/main/README.md

This proposal introduces a configurable, browser-managed retry mechanism within fetch(). It allows web developers to indicate that a fetch() request should be retried, to have a greater guarantee on it being reliably sent, even if the network is flaky. 

```js
// --- Example Usage ---

fetch("/api/important-beacon?id=12345",  {
  method: "GET",
  keepalive: true, // Essential for retryAfterUnload: true
  retryOptions:  {
    maxAttempts: 3,        // Max 3 retries (4 total attempts)
    initialDelay: 500,    // Start with 500ms delay
    backoffFactor: 2.0, // Double delay each time (500ms, 1s, 2s)
    maxAge: 60000,        // Give up after 60 seconds total retry time
    retryAfterUnload: true  // Allow retries to continue even if page closes
  }
});

```

### Anything else?

_No response_

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/fetch/issues/1838
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/fetch/issues/1838@github.com>