Expand description
Retry requests
A Client has the ability to retry requests, by sending additional copies
to the server if a response is considered retryable.
The Builder makes it easier to configure what requests to retry, along
with including best practices by default, such as a retry budget.
§Defaults
The default retry behavior of a Client is to only retry requests where an
error or low-level protocol NACK is encountered that is known to be safe to
retry. Note however that providing a specific retry policy will override
the default, and you will need to explicitly include that behavior.
All policies default to including a retry budget that permits 20% extra requests to be sent.
§Scoped
A client’s retry policy is scoped. That means that the policy doesn’t apply to all requests, but only those within a user-defined scope.
Since all policies include a budget by default, it doesn’t make sense to apply it on all requests. Rather, the retry history applied by a budget should likely only be applied to the same host.
§Classifiers
A retry policy needs to be configured with a classifier that determines if a request should be retried. Knowledge of the destination server’s behavior is required to make a safe classifier. Requests should not be retried if the server cannot safely handle the same request twice, or if it causes side effects.
Some common properties to check include if the request method is idempotent, or if the response status code indicates a transient error.
Structs§
- Builder
- Builder to configure retries