Trait Policy
pub trait Policy<R, E>:
Send
+ Sync
+ 'static {
// Required methods
fn retry(
&self,
req: Request<RetryBody>,
result: Result<R, E>,
) -> impl Future<Output = PolicyResult<R, E>> + Send;
fn clone_input(
&self,
req: &Request<RetryBody>,
) -> Option<Request<RetryBody>>;
}http and std only.Expand description
A “retry policy” to classify if a request should be retried.
§Example
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<R, E> Policy< R, E> for Attempts
where
R: Send + 'static,
E: Send + Sync + 'static,
{
async fn retry(&self, req: Request<RetryBody>, result: Result<R, E>) -> PolicyResult<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 { req }
} else {
// Used all our attempts, no retry...
PolicyResult::Abort(result)
}
}
}
}
fn clone_input(&self, req: &Request<RetryBody>) -> Option<Request<RetryBody>> {
Some(req.clone())
}
}Required Methods§
fn retry(
&self,
req: Request<RetryBody>,
result: Result<R, E>,
) -> impl Future<Output = PolicyResult<R, E>> + Send
fn retry( &self, req: Request<RetryBody>, result: Result<R, E>, ) -> impl Future<Output = PolicyResult<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::Output 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. Mutate the handed-in request in place — its
Extensions are the caller’s
store, so recorded metadata both reaches the next attempt and stays
visible to the caller after the call. Returning a freshly built request
instead keeps its body and headers but not its extensions: each attempt
is re-forked from the caller’s store (see the
module docs).
§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.
As above, record such metadata on the handed-in request (e.g. the number of retries required, or that a failure exhausted all retries).
Dyn Compatibility§
This trait is not dyn compatible.
In older versions of Rust, dyn compatibility was called "object safety".