README.md in faraday-retry-2.0.0 vs README.md in faraday-retry-2.1.0
- old
+ new
@@ -1,8 +1,8 @@
# Faraday Retry
-[](https://github.com/lostisland/faraday-retry/actions?query=branch%3Amain)
+[](https://github.com/lostisland/faraday-retry/actions/workflows/ci.yaml)
[](https://rubygems.org/gems/faraday-retry)
[](LICENSE.md)
The `Retry` middleware automatically retries requests that fail due to intermittent client
or server errors (such as network hiccups).
@@ -98,21 +98,31 @@
#### Automatically handle the `Retry-After` and `RateLimit-Reset` headers
Some APIs, like the [Slack API](https://api.slack.com/docs/rate-limits), will inform you when you reach their API limits by replying with a response status code of `429`
and a response header of `Retry-After` containing a time in seconds. You should then only retry querying after the amount of time provided by the `Retry-After` header,
-otherwise you won't get a response. Other APIs communicate their rate limits via the [RateLimit-xxx](https://tools.ietf.org/id/draft-polli-ratelimit-headers-00.html#rfc.section.3.3) headers
+otherwise you won't get a response. Other APIs communicate their rate limits via the [RateLimit-xxx](https://www.ietf.org/archive/id/draft-ietf-httpapi-ratelimit-headers-05.html#name-providing-ratelimit-fields) headers
where `RateLimit-Reset` behaves similarly to the `Retry-After`.
You can automatically handle both headers and have Faraday pause and retry for the right amount of time by including the `429` status code in the retry statuses list:
```ruby
retry_options = {
retry_statuses: [429]
}
```
+If you are working with an API which does not comply with the Rate Limit RFC you can specify custom headers to be used for retry and reset.
+
+```ruby
+retry_options = {
+ retry_statuses: [429],
+ rate_limit_retry_header: 'x-rate-limit-retry-after',
+ rate_limit_reset_header: 'x-rate-limit-reset'
+}
+```
+
#### Specify a custom retry logic
You can also specify a custom retry logic with the `retry_if` option.
This option accepts a block that will receive the `env` object and the exception raised
and should decide if the code should retry still the action or not independent of the retry count.
@@ -140,10 +150,10 @@
For example, you might want to keep track of the response statuses:
```ruby
response_statuses = []
retry_options = {
- retry_block: -> (env:, options:, retries_remaining:, exception:, will_retry_in:) { response_statuses << env.status }
+ retry_block: -> (env:, options:, retry_count:, exception:, will_retry_in:) { response_statuses << env.status }
}
```
## Development