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

rakina left a comment (whatwg/fetch#1838)

Hmmm, ok, so what is the ideal way for this to alleviate the CORS concerns?
1. Add "Sec-" prefix to the header to identify that only the browser could've set it. Is this acceptable? Or is not encouraged? 
2. Only send `Retry-Attempts` and `Retry-GUID` cross-origin if the headers are in the `Access-Control-Request-Headers`. If they don't exist in the header, or the request is no-cors, should we stop retrying? Or should we retry but without the headers?
3. Something else?

(I'm not very familiar with what is generally OK or not wrt CORS, so thanks in advance for guidance!)

> retryAfterUnload: true It's not clear to me why this is needed. Can't this be derived from keepalive or fetchLater()? When do you want keepalive, but no retries?

Yeah most use case I know would set it to true, but keepalive itself only keeps alive the request for 30s (in Chromium) after the initial request is sent. Meanwhile the retry after unload can happen significantly later (minutes/hours, with the same-NIK-doc constraint) so it's different enough in scale to potentially not want this even with keepalive? I don't have a strong opinion here though. 

> I'm fairly convinced we need to move to the model suggested above where you either get a response (early) or you get a network error at maxAge, but you'll never get a network error early. This reveals the least amount of information and allows user agents to optimize the most when it comes to battery and such.

So in the current proposal, you get the final network error (the one that cannot be retried, e.g. if you exhausted all retries) if the initiator document is still alive (if it's not, nothing can listen to the error). If you get a non-network-error during retry, then you get that result (and no further retries will be attempted). I'm not sure what the difference here is except that the final network error is punted until kMaxAge? Is it better to delay when we know the final result already?

> maxAttempts unsigned long long seems a bit big for this? Do we want the specification to enforce a maximum value and throw? Should we give delay and its multiplier default values?

Oh yeah that's just human error. Maybe `unsigned short` or even `unsigned char` if those are typically used? The defaults in Chrome are [here](https://source.chromium.org/chromium/chromium/src/+/main:content/browser/loader/keep_alive_url_loader.cc;l=61;drc=ddf7f5c6e19d7b1258b0b325baec800ea57c20ed):
- `max_retry_count`: 10 (with additional bounds of 20 per renderer process, 50 per Network Isolation Key)
- `min_retry_delta`: 5s
- `min_retry_backoff`: 1.0
- `max_retry_age`: 1d

Those bounds are just picked randomly, and we can adjust them if there are better options. I'm not sure if these needs to be standardized or just left to each user agent's policy?

> Have you looked at how existing JavaScript libraries are solving this and what their APIs look like? And what APIs look like in other networking environments?

From the developer request linked above, there's https://github.com/sindresorhus/p-retry and https://www.npmjs.com/package/fetch-retry.

Both of them seem quite similar to this proposal, but they don't have the capability to retry after unload (which requires tricky coordination between documents in the same browsing session). They also have a way to set callbacks that can run on every error to determine whether to continue retrying or not. I think that's a possible extension for this proposal, but for now I think we can start with the MVP that is opaque / only exposes the final result.  Then if there's significant interest, we can extend to have something like that too. Although it's going to be a bit tricky if the initiator document is already unloaded.

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

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