Built-in Retry Mechanism

[okalil]

This proposal aims to provide a built-in way to enable retries for Router loaders, specially useful for unstable network conditions, providing a better user experience

Proposal

Add a new retry property to the following methods:

fetcher.load("/route", { retry: 3 })
revalidator.revalidate({ retry: 3 })
navigate("/route", { retry: 3 })

The retry property can also be a function:

fetcher.load("/route", { retry: (error, attempts) => isNetworkError(error) ? attempts < 3 : false }

Event if the load fails, if there's a one more attempt to be done, the "state" will continue as "loading". Only after all attempts fail, the ErrorBoundary will be rendered.

[brophdawg11]

Closing in favor of the canonical custom-fetch proposal, being implemented in PR #15586.

The proposed HydratedRouter.unstable_fetch hook lets Framework Mode apps implement transport retries centrally. Keep the callback's promise pending while retrying a loader request and the router continues waiting; return the eventual compatible response, or throw after exhausting retries to follow the normal error path. Request context can select different policies for navigation, fetchers, and revalidation.

Retry policies should respect request.signal, never retry cancellation, and avoid automatically retrying non-idempotent action submissions. This is a userland transport policy rather than built-in per-call retry options; it does not retry arbitrary loader/action exceptions or automatically cover Data Mode loaders. Browser-managed data prefetches also bypass the hook.

The implementation PR is still open; follow #15461/#15586 for progress.

Authored by an AI agent on behalf of @brophdawg11