grpc-managed-channel sender ignores exporter RetryPolicy

[overmeulen]

Is your feature request related to a problem? Please describe.
We use opentelemetry-java in our platform and since #2995 all the services that start before the opentelemetry collector generate an ERROR log because the collector is not available yet:
https://github.com/open-telemetry/opentelemetry-java/blob/main/exporters/otlp/all/src/main/java/io/opentelemetry/exporter/otlp/internal/GrpcExporter.java#L100

Describe the solution you'd like

Describe alternatives you've considered

Additional context
We're using opentelemetry-java 1.63.0

[jack-berg]

For most users, its pretty important to know that the OTLP receiver you're exporting to isn't available

[overmeulen]

Actually my problem is that I'm getting this error log right away, even when I set a retry policy.
I dug a bit more and it seems to come from the fact that I'm using the grpc-managed-channel, not the default okhttp provider.
The grpc-managed-channel sender ignores the RetryPolicy defined in the exporter...
UpstreamGrpcSenderProvider.minimalFallbackManagedChannel should take the RetryPolicy and apply it.
(I'll rename this issue accordingly)

[jack-berg]

Ah that is more clarifying.

UpstreamGrpcSenderProvider.minimalFallbackManagedChannel should take the RetryPolicy and apply it.

We made a decision a while back to not do this. The idea with UpstreamGrpcSender and minimalFallbackManagedChannel is that if you're using UpstreamGrpcSender, you are almost certainly doing so because you want to exert fine grain control of the channel configuration, outside of the configuration options we expose. And we let you do so. But if you omit your own managed channel, we do not try to map all the configuration options of our OtlpGrpc{Signal}ExporterBuilder to the managed channel.

We recommend using io.opentelemetry:opentelemetry-exporter-sender-okhttp or io.opentelemetry:opentelemetry-exporter-sender-jdk sender: https://opentelemetry.io/docs/languages/java/sdk/#senders

These will respect all the configuration options from the builder.

We think of UpstreamGrpcSender as a fallback sender maintained for backwards compatibility and historical reasons.

[overmeulen]

In our case we're not really using it for fine grain control of the channel.
It's just that we don't want the kotlin dependency coming with io.opentelemetry:opentelemetry-exporter-sender-okhttp and io.opentelemetry:opentelemetry-exporter-sender-jdk does not support gRPC...