Description
For gRPC OTLP exporters, I'm wondering if we should just use gRPC's retry config: https://grpc.io/docs/guides/retry/#retry-configuration, rather than having custom back off/retry code... I'm refactoring the python gRPC exporter a bit now and came across this.
gRPC retry config does not respect the RetryInfo
proto described in https://github.com/open-telemetry/opentelemetry-proto/blob/main/docs/specification.md#failures.
There's nothing that mentions RetryInfo
on the gRPC repo / website. RetryInfo
is mentioned in some Google AIP's, it's a Google published proto, it is used by some Google APIs (mainly for when quota based errors should be retried).
gRPC has a supported header (grpc-retry-pushback-ms
) for server pushback: https://github.com/grpc/proposal/blob/master/A6-client-retries.md#pushback. I tested this header and it is supported by gRPC's retry config.
I'm wondering if it's acceptable to use gRPC retry config given it diverges from the spec a little, or if we should update the spec to recommend this other header..
I feel it's nice to let the gRPC library handle this stuff instead of hand rolling our own code. If gRPC changes something around retries I'm assuming they'd update their own retry handling code and we wouldn't have to worry about it.
Metadata
Metadata
Assignees
Labels
Type
Projects
Status