pub trait Policy<S, R, E>: Send + Sync + 'static {
// Required methods
fn retry(
&self,
ctx: Context<S>,
req: Request<RetryBody>,
result: Result<R, E>,
) -> impl Future<Output = PolicyResult<S, R, E>> + Send;
fn clone_input(
&self,
ctx: &Context<S>,
req: &Request<RetryBody>,
) -> Option<(Context<S>, Request<RetryBody>)>;
}Expand description
A “retry policy” to classify if a request should be retried.
§Example
use rama_core::Context;
use rama_http::Request;
use rama_http::layer::retry::{Policy, PolicyResult, RetryBody};
use std::sync::Arc;
use parking_lot::Mutex;
struct Attempts(Arc<Mutex<usize>>);
impl<S, R, E> Policy<S, R, E> for Attempts
where
S: Send + Sync + 'static,
R: Send + 'static,
E: Send + Sync + 'static,
{
async fn retry(&self, ctx: Context<S>, req: Request<RetryBody>, result: Result<R, E>) -> PolicyResult<S, R, E> {
match result {
Ok(_) => {
// Treat all `Response`s as success,
// so don't retry...
PolicyResult::Abort(result)
},
Err(_) => {
// Treat all errors as failures...
// But we limit the number of attempts...
let mut attempts = self.0.lock();
if *attempts > 0 {
// Try again!
*attempts -= 1;
PolicyResult::Retry { ctx, req }
} else {
// Used all our attempts, no retry...
PolicyResult::Abort(result)
}
}
}
}
fn clone_input(&self, ctx: &Context<S>, req: &Request<RetryBody>) -> Option<(Context<S>, Request<RetryBody>)> {
Some((ctx.clone(), req.clone()))
}
}Required Methods§
fn retry(
&self,
ctx: Context<S>,
req: Request<RetryBody>,
result: Result<R, E>,
) -> impl Future<Output = PolicyResult<S, R, E>> + Send
fn retry( &self, ctx: Context<S>, req: Request<RetryBody>, result: Result<R, E>, ) -> impl Future<Output = PolicyResult<S, R, E>> + Send
Check the policy if a certain request should be retried.
This method is passed a reference to the original request, and either
the Service::Response or Service::Error from the inner service.
If the request should not be retried, return None.
If the request should be retried, return Some future that will delay
the next retry of the request. This can be used to sleep for a certain
duration, to wait for some external condition to be met before retrying,
or resolve right away, if the request should be retried immediately.
§Mutating Requests
The policy MAY chose to mutate the req: if the request is mutated, the
mutated request will be sent to the inner service in the next retry.
This can be helpful for use cases like tracking the retry count in a
header.
§Mutating Results
The policy MAY chose to mutate the result. This enables the retry policy to convert a failure into a success and vice versa. For example, if the policy is used to poll while waiting for a state change, the policy can switch the result to emit a specific error when retries are exhausted.
The policy can also record metadata on the request to include information about the number of retries required or to record that a failure failed after exhausting all retries.