- From: Rakina Zata Amni <notifications@github.com>
- Date: Fri, 27 Jun 2025 06:17:53 -0700
- To: whatwg/fetch <fetch@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <whatwg/fetch/issues/1838@github.com>
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>
Received on Friday, 27 June 2025 13:17:57 UTC