You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
configgrpc and confighttp both allow setting a headers section to set headers on client requests. However, while confighttphandles this internally, configgrpc does not, as there doesn't seem to be a way to set headers on the grpc.ClientConn struct it returns. The OTLP/gRPC exporter fills the gap by extracting the headers config, wrapping it in a metadata.MD, then later adding it to the Context passed to the gRPC call, which is then taken into account by the gRPC library.
This is not ideal, as it means the configgrpc.ClientConfig.Headers is a no-op by default, and components using a gRPC client must manually do this abstraction-leaking processing to take it into account.
Proposed solution:
I considered wrapping grpc.ClientConn to automatically add the metadata in Invoke calls, but because the code calling this method is generated by protogen and expects a grpc.ClientConn specifically, this does not seem possible.
My proposed solution is a new method on ClientConfig which adds the headers to a provided Context, and documenting that the Headers field requires calling this function and passing the resulting Context into the gRPC call.
Update: We can actually do it pretty simply with grpc.WithUnaryInterceptor.
The text was updated successfully, but these errors were encountered:
#### Description
This PR uses the `grpc.WithUnaryInterceptor` option to add the metadata
configured in `ClientConfig.Headers` automatically to requests made with
the created `grpc.ClientConn`. Currently, users of `configgrpc` must
extract the headers from the config and insert them manually in each
request.
The current implementation is meant to be backward-compatible with code
that manually inserts the headers: if a header key is already present in
the `Context` passed to the interceptor, it will not be modified and no
duplicate will be added.
#### Link to tracking issue
Fixes#12307
#### Testing
The tests in `otlpexporter` check that headers are properly inserted,
and they still pass after removing the OTLP-specific headers code. I
also added a new test in configgrpc for testing unary RPC calls.
I'm not sure how to easily test streaming RPC calls however (hence the
lacking code coverage), but since [the
docs](https://github.com/grpc/grpc-go/blob/master/Documentation/grpc-metadata.md)
imply that adding metadata to streaming RPC calls is the same as unary
calls, it should hopefully work.
Problem:
configgrpc
andconfighttp
both allow setting aheaders
section to set headers on client requests. However, whileconfighttp
handles this internally,configgrpc
does not, as there doesn't seem to be a way to set headers on thegrpc.ClientConn
struct it returns. The OTLP/gRPC exporter fills the gap by extracting theheaders
config, wrapping it in ametadata.MD
, then later adding it to theContext
passed to the gRPC call, which is then taken into account by the gRPC library.This is not ideal, as it means the
configgrpc.ClientConfig.Headers
is a no-op by default, and components using a gRPC client must manually do this abstraction-leaking processing to take it into account.Proposed solution:
I considered wrappinggrpc.ClientConn
to automatically add the metadata inInvoke
calls, but because the code calling this method is generated by protogen and expects agrpc.ClientConn
specifically, this does not seem possible.My proposed solution is a new method onClientConfig
which adds the headers to a providedContext
, and documenting that theHeaders
field requires calling this function and passing the resultingContext
into the gRPC call.Update: We can actually do it pretty simply with
grpc.WithUnaryInterceptor
.The text was updated successfully, but these errors were encountered: