-
Notifications
You must be signed in to change notification settings - Fork 271
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
RetryPolicy refactor suggestions #1045
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm, i'm on board with all these suggestions! i did leave a comment on the trait naming thing explaining my original thought process, but i'm not attached to it at all --- this is probably better. other than that, nothing stood out, thanks!
/// Constructs a boxing layer that erases the inner request type with [`EraseRequest`]. | ||
pub fn erased() -> impl layer::Layer<S, Service = EraseRequest<S>> + Clone + Copy { | ||
EraseRequest::layer() | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍
/// An extension to [`tower::retry::Policy`] that adds a method to prepare a | ||
/// request to be retried, possibly changing its type. | ||
pub trait RetryPolicy<Req, Res, E>: tower::retry::Policy<Self::RetryRequest, Res, E> { | ||
pub trait PrepareRequest<Req, Res, E>: tower::retry::Policy<Self::RetryRequest, Res, E> { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
my original motivation for naming this RetryPolicy
--- which i agree is a bit confusing --- was because it requires tower
's RetryPolicy
trait, so when it's used, we only bound the type with this trait.
i also considered the name PrepareRequest
, but it seemed kind of weird to me to require that the policy implement PrepareRequest
and not mention that it is also a retry policy? maybe that's not actually worth worrying about, and i'm fine with this naming scheme if you think it's clearer...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
could call it PreparePolicy
or something like that -- but RetryPolicy vs Policy is a bit too subtle imo
A few suggestions on #1043
EraseRequest
viaBoxRequest::erased
-- we don't actually care about the different types--the behavior is basically the same -- there's just some minor differences with regards to preserving marker types. It reads a little bit more naturally if we just hang it all off BoxRequest.linkerd_retry::RetryPolicy
trait tolinkerd_retry::PrepareRequest
(to match its only method). It's a bit... malkovich to have bothtower::retry::Policy
andlinkerd_retry::RetryPolicy
which are closely related but different.linkerd_retry
now re-exports relevanttower::retry
types.app::core::retry
to reflect actual types. For instance,NewRetry
is nowNewRetryPolicy
-- since it actually implementsNewPolicy
and has nothing to do with theretry::NewRetry
type.NewRetryLayer
eliminated in favor of an anonymous type.inlines
on pass-through service/proxy methods