The C++ gRPC server sometimes returns both headers and trailers. An
excerpt from Wireshark:
```
Stream: HEADERS, Stream ID: 1, Length 136, 200 OK
Header: :status: 200 OK
Header: x-middleware: expected value
Header: content-type: application/grpc
Header: grpc-accept-encoding: identity,deflate,gzip
Header: accept-encoding: identity,gzip
Stream: HEADERS, Stream ID: 1, Length 92
Header: grpc-status: 2
Header: grpc-message: Unknown
Header: x-arrow-status: 9
Header: x-arrow-status-message-bin: VW5rbm93bg
```
Before this commit, only the metadata from the trailer would be
available, missing the `x-middleware` header:
```
MetadataMap {
headers: {
"x-arrow-status-message-bin": "VW5rbm93bg",
"x-arrow-status": "9",
},
}
```
* fix(transport): reconnect lazy connections after first failure
Channels created with lazy connections never try to reconnect if the
first connection attempt fails. This is because `Reconnect` returns
`Poll::Ready(Err)` on poll_ready and the service is considered dead.
This change passes a flag to Reconnect to signal if the connection
is intended to be lazy, in which case reconnect returns the error on
the next call.
fixes#452
Before this fix, if the connect phase of the transport failed before
ever establishing a connection, we would never return the error until
the first call to send a request. This PR changes that behavior to only
forward the error to the call method if we have ever made a connection
before. If we have never established a connection before then
`Reconnect` will return an error on the call to `poll_ready`.
Fixes#403
* examples: update to `tracing` 0.1.14, use `#[instrument]`
Now that `tracing-attributes`'s `#[instrument]` macro plays nicely with
`async-trait`, we can update the tracing example to use `instrument`.
This lets us simplify the events emitted in the example.
Signed-off-by: Eliza Weisman <[email protected]>
* feat(transport): Dynamic load balancing (#341)
* Fix typo (#356)
Co-authored-by: Dawid Nowak <[email protected]>
Co-authored-by: Paulo Duarte <[email protected]>
* Propagate errors in tls_config instead of unwrap
Ran into `tls_connector` failing and causing our app to panic and shutdown as it seems there wasn't any way to avoid panicking in `tls_config`.
So after talking to @LucioFranco briefly `tls_config` now returns a `Result` instead and propagates errors to the caller, where they can be handled.
* Fix compile warning when tls feature is disabled
This change reverts #366. The `proto/` directory, as described in the guide,
is created under the root of the crate. Not under `src/`.
I've also included a fix to the `grpcurl` endpoint.
Fixed wrong path "proto/helloworld.proto" for `compile_protos` first argument. `build.rs` being in the project root, means the correct path should be "src/proto/helloworld.proto".
