opentelemetry-collector-contrib: version command prints jaeger errors

This is caused by both the Jaeger receiver and the Coralogix exporter registering the same types:

This is a transitive dependency of the coralogix exporter: https://github.com/coralogix/opentelemetry-cx-protobuf-api/blob/d2a5d0ecf53ef7d38129bc756009169c4c32167f/collector.pb.go#L182-L186

@oded-dd @ofirshmuel, any reason you are not using your own namespaces for that?

Let me ping them one last time and send an email to the email on @oded-dd’s bio:

@oded-dd @ofirshmuel if you don’t actively fix issues from your exporter your component may get excluded from the default build, making it harder to be used. Please take a look at the issue as soon as you can.

If there is no answer, let’s bring this up on the next Collector SIG

Hey! Sorry somehow missed the ping on this issue. Working on the fix in https://github.com/open-telemetry/opentelemetry-collector-contrib/pull/16573

Okay, I have labeled this as exporter/coralogix instead of Jaeger, AIUI the fix needs to be done in the Coralogix exporter.

We got no answer here or in the email, thus I added this to today’s SIG agenda. cc @oded-dd @ofirshmuel @jpkrohling

@mx-psi yes its still a thing. d397c9878974186e6cf66f904b364d7fc983b691

2022/11/10 11:29:59 proto: duplicate proto type registered: jaeger.api_v2.PostSpansRequest
2022/11/10 11:29:59 proto: duplicate proto type registered: jaeger.api_v2.PostSpansResponse

@frzifus thank you for your help. Adding @povilasv to the thread. He’ll probably also attend it soon, and could give you all the insights you need.

This is caused by both the Jaeger receiver and the Coralogix exporter registering the same types

I am surprised that it this exporter workes. 🙅. There are two definitions of jaeger.api_v2.PostSpansRequest, jaeger and coralogix. For me it looks like carologix is adding the message Metadata it the request.

+ message Metadata {
+     string ApplicationName = 1;
+     string SubsystemName = 2;
+ }

message PostSpansRequest {
    Batch batch = 1 [
        (gogoproto.nullable) = false
    ];
+     Metadata metadata = 2;
}

As far as I understand, this leads to a few problems:

1. it is not clear which of the two messages is registered first. Seems to be decided at each program start. As a result we can not make sure that Metadata will be a part of PostSpansRequest.
2. If the jaeger would get extended in the future this could cause issues there too.
3. Maybe in the future the type registration will follow a similar approach as other register methods and will end with a panic in case of a double registration.

---

Any recommendations how to solve this?

cc @oded-dd @ofirshmuel @jpkrohling

Hi @jpkrohling , we are investigating this issue.