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

rakina left a comment (whatwg/fetch#1838)

> My understanding is that browsers already do extensive retrying of failed requests, including POSTs (etc.) in some circumstances (e.g., if the connection is dropped before the request body is complete).
> Is this proposal attempting to capture all of those use cases and surface them as Fetch arguments, or is this purely for non-platform consumers of fetch?

So this mostly comes from an observation even with the internal retries, we still see some amount of what seems like transient network errors as the end result. I guess the internal retries need to somewhat be careful to not have unintended consequences, meanwhile this API is an explicit signal that it's ok to retry. So this is a stronger version of that (and the fact that there are existing libraries that attempt to do just this, it seems useful enough).

> I would keep the new request headers out of v1. As Mark notes there's overlap with IETF activity and it also seems fairly high-level for a low-level API such as fetch(). I'm also not entirely comfortable sharing this additional information about the end user's network environment with the server.

Yeah this is probably OK. I guess it's easy enough for devs to manually add `Retry-GUID` if they want to. `Retry-Attempts` isn't quite possible if we don't expose intermediate errors, but maybe it's ok to not have that, as it's not important to dedup.
If we don't have these headers, is there still a problem with `no-cors`?

> Delivering the final network error upon max-age frees us from any worries about timing attacks and allows us to end retrying early and preserve end user resources when it's due to a policy, battery, or other relevant concern. Because of this we should probably require max-age to always be set.

OK. Does this mean if we only expose at maxAge, there's no problem if we retry only on certain errors (e.g. transient network errors, or only on errors where we're sure that the server is not reached yet?). For all of them they will only hear back on kMaxAge.

> I think we should have recommended default values for delay and delayFactor. If we don't and they end up significantly varying across implementations, web developers will feel required to always set them instead. Alternatively we could require them to be always be set in v1 and throw otherwise, that would also be reasonable.

Sure, I think I'll propose the Chromium defaults, or maybe we'll come up with better limits later.

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

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