New Proposal: Fetch retry

[rakina]

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.

// --- 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

[erik-anderson]

One of the concerns with Service Worker background sync was that it may allow leaking information about different networks a given device is using over time.

A site could presumably abuse this mechanism to achieve that as well. It could set up an endpoint that always terminates the connection after receiving the URL in such a way that it generates a fetch failure for the client. It could then observe the future retries, even if they were hours or days later.

To mitigate that risk, should there be a cap on how long (wall clock time) a retry will be attempted? And/or should it only attempt a retry if it looks like it's still on the same network interface, proxy configuration, and/or other networking configuration?

I do see the explainer notes that there should be some browser-enforced limit on maxAge, but it's coming from a resource exhaustion angle vs. an info leak. Is there a proposed recommended limit?

[annevk]

What happens if fetch returns a network error due to a policy?