Skip to content

Question about gRPC error handling specification #4513

Open
@DylanRussell

Description

@DylanRussell

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

spec:protocolRelated to the specification/protocol directorytriage:accepted:ready-with-sponsorReady to be implemented and has a specification sponsor assigned

Type

No type

Projects

Status

No status

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions