retry: handle unexpected float delays

[ssaunderss]

When retry delays were introduced in #226 it was implied that the retry delay would be greater than or equal to 1s. In situations where retry delays are either passed back as floats and/or less than 1s, it would be nice to use full precision since we're converting to milliseconds anyway.

This specifically fixes a problem in my case where an API is consistently handing back retries that are less than 1s, i.e. 0.314s.

[wojtekmach]

Thank you for the PR. Could you add a unit test?

[wojtekmach]

Could you double check if fractions are allowed by RFC 9110? If not we shouldn’t change this parsing, perhaps the issue is somewhere else.

[ssaunderss]

I think it's a bit of a grey area - RFC 9110 dictates that it should be a non-negative integer, but APIs / rate limiters often pass back fractional values because they're just doing a raw date diff. Maybe a better way to handle this is to continue parsing as an integer, but handle the case where a fractional part is present by just adding an extra second?

It would be nice to handle this at the library level instead of having to add boilerplate for handling errors downstream.

[ssaunderss]

I made some updates based on the approach above and added some test coverage for get_retry_after

[ssaunderss]

@wojtekmach I've made the suggested changes and added tests. Would you have time to review this approach of handling fractional delays by rounding up? Let me know if I should close this PR or if you'd like additional changes.

[wojtekmach]

Apologies for delay. My bad. I think your solution is pragmatic however to be completely honest I'm not keen on accommodating broken servers that do not follow the spec. Looks like curl and Python requests ignore such invalid value for what it's worth.

We have some escape hatches in https://hexdocs.pm/req/Req.Steps.html#retry/1. Would any of these work for you? Using retry: &fun/2 you could see if the header is there and if parsing with Req.Response.get_retry_after/1 is unsuccessful, try parsing it as a float and return {delay, ms}.

If the current retry: fun interface would not work for you I'm much more keen on making it more useful to solve this and other edge cases. We have some open issues around this so if you'd be interested in going in that direction check them out first:

• retry: Make retry interface a bit more flexible #202
• retry: Allow changing of initial request parameters #296
• Would it make sense to make retry transient? function public? #371

[ssaunderss]

Thanks for the response. I believe I should be able to handle it using a custom retry function. In the meantime, I'll also take a look into those related issues!