Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve README.md about exceptions config #35

Merged
merged 2 commits into from
Feb 20, 2024
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
12 changes: 9 additions & 3 deletions README.md
Original file line number Diff line number Diff line change
Expand Up @@ -75,7 +75,7 @@ retry_options = {
#### Specify which exceptions should trigger a retry

You can provide an `exceptions` option with a list of exceptions that will replace
the default list of network-related exceptions: `Errno::ETIMEDOUT`, `Timeout::Error`, `Faraday::TimeoutError`.
the default exceptions: `Errno::ETIMEDOUT`, `Timeout::Error`, `Faraday::TimeoutError`, `Faraday::Error::RetriableResponse`.
This can be particularly useful when combined with the [RaiseError][raise_error] middleware.

```ruby
Expand All @@ -84,6 +84,14 @@ retry_options = {
}
```

If you want to inherit default exceptions, do it this way.

```ruby
retry_options = {
exceptions: Faraday::Retry::Middleware::DEFAULT_EXCEPTIONS + [Faraday::ResourceNotFound, Faraday::UnauthorizedError]
}
```

#### Specify on which response statuses to retry

By default the `Retry` middleware will only retry the request if one of the expected exceptions arise.
Expand Down Expand Up @@ -144,10 +152,8 @@ retry_options = {
You can specify a proc object through the `retry_block` option that will be called before every
retry, before There are many different applications for this feature, spacing from instrumentation to monitoring.


The block is passed keyword arguments with contextual information: Request environment, middleware options, current number of retries, exception, and amount of time we will wait before retrying. (retry_block is called before the wait time happens)


For example, you might want to keep track of the response statuses:

```ruby
Expand Down