fix: Use retry-after response header if missing in the response body for 429 API bans

[Daniel-Worrall]

Summary

In the case of a 429 after an API ban, the retry-after in the JSON body isn't present, but is present in the headers.

The library will incorrectly wait for 0.0s since it's nil in the body and spam the API. This fixes this issue.

Fixed

Use retry-after response header if retry-after is missing in the response body

[sadleb]

Related PR for reference:

• fix: 429 runaway retry. retry_after is in seconds and so is sleep #114

We just had this re-surface today and continue to dig into the root cause of the 429 ban in the first place.

[sadleb]

Related PR for reference:

• fix: 429 runaway retry. retry_after is in seconds and so is sleep #114

We just had this re-surface today and continue to dig into the root cause of the 429 ban in the first place.

fyi: Apparently it's b/c we shared an IP address with others and either they were making too many requests and got rate-limited or the aggregate of all requests sharing that IP address led to rate-limiting for requests coming from it. This app is on Heroku.

[swarley]

The root cause of the reported issue was due to a known problem with Discord and hosts that have shared IPs. This fix is still a good one because it's possible that Discord will send a 429 that does not include the more precise value in the body. Thanks @Daniel-Worrall! 🚀