Module classifiers

Available on crate feature client only.

Classifiers for determining if a retry is necessary and related code.

When a request fails, a retry strategy should inspect the result with retry classifiers to understand if and how the request should be retried.

Because multiple classifiers are often used, and because some are more specific than others in what they identify as retryable, classifiers are run in a sequence that is determined by their priority.

Classifiers that are higher priority are run after classifiers with a lower priority. The intention is that:

1. Generic classifiers that look at things like the HTTP error code run first.
2. More specific classifiers such as ones that check for certain error messages are run after the generic classifiers. This gives them the ability to override the actions set by the generic retry classifiers.

Put another way:

large nets target common failures with basic behavior	run before	small nets target specific failures with special behavior
low priority classifiers	results overridden by	high priority classifiers

Structs

• RetryClassifierPriority
  The priority of a retry classifier. Classifiers with a higher priority will run after classifiers with a lower priority and may override their result. Classifiers with equal priorities make no guarantees about which will run first.
• SharedRetryClassifier
  Retry classifier used by the retry strategy to classify responses as retryable or not.

Enums

• RetryAction
  The result of running a ClassifyRetry on a InterceptorContext.
• RetryReason
  The reason for a retry.

Traits

• ClassifyRetry
  Classifies what kind of retry is needed for a given InterceptorContext.