At Embark we have a little helper function that converts a `&dyn
std::error::Error` into a `String` by walking the full chain of sources
(with `std::error::Error::source`) and joining them into a `String`.
We use that where we log errors to get as much information as possible
about whats causing an error. Works particularly well with anyhow's
`.context()` method.
However since `tonic::transport::Error` include its cause in their
`Display` impl we get the sources more than once.
As the cause can already be obtained through `std::error::Error::source`
no information should be lost by doing this.
Fixes https://github.com/hyperium/tonic/issues/632
As of `http-body` 0.4.1 its has had a `BoxBody` type similar to
`tonic::body::BoxBody`. It also has `Empty` and `Body::map_{data,err}`.
That means all the custom body things we had in tonic can basically be
replaced with that.
Note that this is a breaking change so we should merge this next time we
decide to ship a breaking release.
The breaking changes are:
- `tonic::body::Body` has been removed. I think its fine for users to
depend directly on `http-body` if they need this trait.
- `tonic::body::BoxBody` is now just a type alias for
`http_body::combinators::BoxBody<Bytes, Status>`. So the methods it
previously had are gone. The replacements are
- `tonic::body::Body::new` -> `http_body::Body::boxed`
- `tonic::body::Body::map_from` -> `http_body::Body::map_data` and
`http_body::Body::map_err` depending on which part you want to map.
- `tonic::body::Body::empty` -> `http_body::Empty`
Additionally a `Sync` bound has been added to a few methods. I actually
don't think this is a breaking change because the old
`tonic::body::Body` trait had `Sync` as a supertrait meaning the `Sync`
requirement was already there.
Fixes https://github.com/hyperium/tonic/issues/557
Adds `tonic::Extensions` which is a newtype around `http::Extensions`.
Request extensions can be set by interceptors with
`Request::extensions_mut` and retrieved from RPCs with
`Request::extensions`. Extensions can also be set in tower middleware
and will be carried through to the RPC.
Since response extensions cannot be set by interceptors the main use
case is to set them in RPCs and retrieve them in tower middlewares.
Figured that might be useful.
Fixes https://github.com/hyperium/tonic/issues/255
`Code` is already trivial to convert into an `i32` however that isn't
immediately obvious by looking at the docs. This has tripped me up
before.
Implementing `From<Code>` for `i32` should hopefully make it a bit more
obvious.
Sometimes error output from rustfmt might be printed to stdout instead
of stderr. So to help users debug rustfmt issues this makes stdout get
printed as well.
Fixes https://github.com/hyperium/tonic/issues/600
Doing
```rust
let clone = self.inner.clone();
Box::pin(async move {
let response = clone.call(request).await?;
Ok(response)
})
```
If `self.inner` is (or contains) a `tower::buffer::Buffer` might panic.
That is because cloning a `Buffer` drops the permit that was acquired in
`poll_ready`, meaning it is no longer ready and panic in `call`.
The solution is to use `mem::replace` to take the ready service and pass
that into the async block.
Fixes https://github.com/hyperium/tonic/issues/545
* transport: Support timeouts with "grpc-timeout" header
* Apply suggestions from code review
Co-authored-by: Lucio Franco <[email protected]>
* Timeout -> GrpcTimeout and export TimeoutExpired
* Clean up imports
* Give header name a more proper home
* Add fuzz tests for parsing header value into `grpc-timeout`
* Map `TimeoutExpired` to `cancelled` status
* Recover from timeout errors in the service
* Refactor tests
* Fix CI
* Fix CI, again
Co-authored-by: Lucio Franco <[email protected]>
* Use new tower utilities
Tower recently introduced `layer_fn` and `ServiceBuilder::option_layer`.
Some very similar things existed in Tonic. This replaces those with what
Tower provides.
* Also use `ServiceBuilder::layer_fn`
In tower 0.4.0 we missed a couple of re-exports that tonic 0.4.0 depends
on. So tonic really depends on tower at least version 0.4.1. Since
specifying your tower depedency as 0.4 means you might get 0.4.0, you
might get build errors when updating tonic. Such as [#553] and [#552].
This fixes that by bumping tonic's dependency on tower to 0.4.4. That
means users will get at least tower version 0.4.4, but semver compatible
updates are still allowed.
Fixes https://github.com/hyperium/tonic/issues/553
[#553]: https://github.com/hyperium/tonic/issues/553
[#552]: https://github.com/hyperium/tonic/issues/552
