-
Notifications
You must be signed in to change notification settings - Fork 50
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
feat(client): remove lifetime requirement for service request #1207
base: main
Are you sure you want to change the base?
feat(client): remove lifetime requirement for service request #1207
Conversation
5bcff12
to
6e1cd01
Compare
Side effect based service call is a design choice on high level of the framework. This is consistent between match service.call(req).await {
Ok(_) => ..
Err(_) => service2.call(req).await
} With traditional function style service call (like most existing Therefore its a trade off between enabling side effect or not but currently we decide it worth to keep it as is and make improvements on the short side of it:
|
This was roughly the plan if this is accepted, something like : match service.call(req).await {
Ok(_) => ..
Err(Error::RetryableErr(req, ..) => service2.call(req).await
Err(_) => ..
}
If there is a plan like this, then yes this PR could be closed |
There may be a third way, most reasons that dispatcher need to have a Maybe the into parts can be done before middleware processing and then the service request will look like : pub struct ServiceRequest<'r, 'b, 'c> {
pub req: &'r mut Request<()>,
pub body: &'b mut BoxBody,
pub client: &'c Client,
pub timeout: Duration,
} Then we could delay taking the request latter in the implementation or we even could clone it since most data of |
6e1cd01
to
03824cc
Compare
My main concern with this change is to be able to end user to know if the request has been used after calling the next middleware. Another proposition would be to propose an enum to the end user like :
then a middleware would be like
Basically the request lifetime would be transfered to the
But end user would have the possibility to know if the request has been used or not (allowing him to retry safely if needed) |
Main purpose of this is, i think this will remove a lot of confusion when creating middleware.
Actually middleware system take a
&mut request
so someone writing a middleware may think that after calling the next middleware we could still read / manipulate the request.However when looking at the implementation for h2 / h3 it will take the request (due to the
core::mem::take
and replace it with default values) If user is not aware of the implementation he may be confused (that was my case when trying this lib for the first time)This change enforce that the request is taken by the next middleware and cannot be read or manipulate after it, unless cloned (like its done for the redirect middleware) and so i believe this will be more understandable for people writing middleware