Include connection info in Client::send_request errors #2749
Conversation
There was a problem hiding this comment.
So, I don't know yet what the best outcome here is. I think including some info in the error is probably a good idea. I think there's some prior art in other libraries, and some potential new features in libstd that we may wish to consider, before refining what exactly we expose.
| @@ -206,9 +211,20 @@ impl Error { | |||
| self.inner.cause | |||
| } | |||
|
|
|||
| /// Returns the info of the client connection on which this error occurred. | |||
| #[cfg(all(feature = "client", any(feature = "http1", feature = "http2")))] | |||
| pub fn client_connect_info(&self) -> Option<&Connected> { | |||
There was a problem hiding this comment.
I realize they're not implemented yet, but this made me think of the errors RFCs about "generic context" access, and would seem like a good fit eventually. rust-lang/rfcs#2895 and rust-lang/rfcs#3192
| @@ -242,7 +242,7 @@ where | |||
| if req.version() == Version::HTTP_2 { | |||
| warn!("Connection is HTTP/1, but request requires HTTP/2"); | |||
| return Err(ClientError::Normal( | |||
| crate::Error::new_user_unsupported_version(), | |||
| crate::Error::new_user_unsupported_version().with_client_connect_info(pooled.conn_info.clone()), | |||
There was a problem hiding this comment.
This also kind of reminds me of how in Finagle, the exceptions/failures there have "sources" and/or "remote info".
There was a problem hiding this comment.
@seanmonstar, not familiar with finagle... Can you point to the library doc or impl. Also would be informative to know an example use you considered best practice or at least idiomatic.
Context: I'm refactoring the traceable errors in my tracing PR and this seems on-point.
|
@seanmonstar Ping on this? |
|
I think including this info in the error somehow is a good goal. We should do it. I want to figure out how exactly that info should be exposed, though. As part of 1.0, the pooling
|
|
IMO for now 2nd way is good, as the client still lives in Hyper. Would you mind we merge this PR as is and see how we do it for 1.0 later? |
|
So, I could just click merge, but it will most likely be different with 1.0 (and that's starting now-ish). How do you feel now? |
|
SGTM, that’s at least one less patch to maintain on my side until 1.0 :)
|
|
@seanmonstar Would you merge it if I rebase it again? |
|
Sure, we can just merge it into 0.14, while noting that a more generic mechanism is probably better for hyper-util (in a hyper 1.0 world). |
No need to map futures as we already await in that method anyway.
|
I rebased it on top of 0.14.x and changed the PR base branch. |
No description provided.