Handle partial-success responses for OTLP trace

[jmacd]

Fixes #3102.

This constructs an error for passing to otel.Handle() from any of the new PartialSuccess messages in OTLP v0.19.

See the specification of this feature.

[codecov]

Codecov Report

Merging #3106 (96eadb0) into main (9c2a0c2) will increase coverage by 0.0%.
The diff coverage is 80.3%.

Additional details and impacted files

@@          Coverage Diff          @@
##            main   #3106   +/-   ##
=====================================
  Coverage   76.4%   76.4%           
=====================================
  Files        179     180    +1     
  Lines      11977   12014   +37     
=====================================
+ Hits        9160    9190   +30     
- Misses      2578    2583    +5     
- Partials     239     241    +2     

Impacted Files	Coverage Δ
exporters/otlp/otlptrace/otlptracehttp/client.go	76.2% <64.2%> (-0.8%)	⬇️
exporters/otlp/otlptrace/otlptracegrpc/client.go	92.5% <100.0%> (+0.3%)	⬆️
exporters/otlp/partialsuccess.go	100.0% <100.0%> (ø)
exporters/jaeger/jaeger.go	90.3% <0.0%> (-0.9%)	⬇️

[jmacd]

Please consider 54d9dcf a question about readability. I rewrote the code to have better coverage (to pass the CI checks), but I'm not sure it's a good trade. OTOH, I feel it's not worth adding specialized tests to ensure that errors-in-response-handling (protobuf error, I/O error, etc.) are covered. What do you think?

[dashpole]

I also prefer the lower-code-coverage version for readability. I would support merging even if it does not pass those checks. Was it failing the required check, or the non-required check?

[MrAlias]

Can we pull the changes to the otlpmetricgrpc package out of the PR? They will conflict with #3094

[jmacd]

I'm not sure anyone is interested in seeing this supported for traces -- from my perspective we may as well wait until after #3094. Thanks @MrAlias.

[jmacd]

I reverted the otlpmetric portion. I also reverted the questionable style in 54d9dcf. (This is no longer a priority for me, however 😁)

[MadVikingGod]

LGTM. The only thing that needs addressing is the closing of the http.body.

[MadVikingGod]

I'm conflicted about where this should live. On the one hand, I would like users to create an ErrorHandler that does something more intelligent than just log a string. On the other hand, I would prefer not to expose a new API surface needlessly.

If no one has any other objections to this than I can live with it.

[jmacd]

I'm a fan of structured logging; I would advocate for a backwards-compatible mechanism to accomplish it. The PartialSuccess error can implement some future API that enables it to be expressed in a structured way when the producer logs it to a structure-aware logger.

I didn't know where to put it either. At this level in the current package structure, it falls into the top-level package, which feels OK to me.

[MadVikingGod]

With no objections to this, we can leave it where it is.

[MrAlias]

I would rather have these live in an internal package, at lease to start.

[MrAlias]

I'm not sure what a user will be able to do with an error handler other than log the error given they cannot retry the export. And adding this to the public API seems like adding something only OTel developers will use or care about, not users.

[MrAlias]

There was an unresolved comment: #3106 (comment)

I would rather have these live in an internal package, at lease to start.

I think this PR was merged pre-maturely.

[MrAlias]

There was an unresolved comment: #3106 (comment)

I would rather have these live in an internal package, at lease to start.

I think this PR was merged pre-maturely.

I'm opening a to address this.