Don't retry upon *any* 5xx status code

[rauchg]

501 for example means Not Implemented. ie: not worth retrying.

500
502
503
504

make sense instead.

[OlliV]

Retry on 502 makes sense at least with our proxies because IIRC it usually means that the backend service is temporarily down.

[jamo]

also 503 (503 is iirc what we give if unfreeze is taking too long (and 502 when there is an issue which is less likely to solve on it's own)

And also 500 might be worth retrying since it's the generic something went wrong (but in that case a longer/steeper retry would make sense. for cases like "overloaded cosmos" etc

[rauchg]

@OlliV that's exactly what I said. We should retry on the ones I listed, but not on any 50x, for example not 501.

[msz]

Retrying within fetch depending on status code does not make sense at all. A response with a status code is a successfully executed request regardless of the status code. Analyzing and responding to status code lies in application layer, not baked inside plumbing such as fetch.

[pke]

That's why maybe opts could contain a "retryIf" function that gets the response and tells if it should retry. If one hands in an array of numbers then this implicit for a function checking those status codes.

[OlliV]

Retrying was implemented here because it made sense to have a shared module that can do it for the backend code at the company, instead of copying and pasting the same handling to every service. Now you see that this is actually a separate module, and not "baked in" feature, so you can easily just drop it and use the other parts of the modular library. There was an example somewhere in the README files.