Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[bridge/ot] Fall-back to TextMap carrier when it's not ot.HttpHeaders #3679

Merged
merged 21 commits into from
Feb 14, 2023

Conversation

yurishkuro
Copy link
Member

Resolves #3678

@codecov
Copy link

codecov bot commented Feb 5, 2023

Codecov Report

Merging #3679 (e6c2d53) into main (f3b4813) will increase coverage by 0.0%.
The diff coverage is 100.0%.

Additional details and impacted files

Impacted file tree graph

@@          Coverage Diff          @@
##            main   #3679   +/-   ##
=====================================
  Coverage   79.6%   79.6%           
=====================================
  Files        171     171           
  Lines      12657   12661    +4     
=====================================
+ Hits       10085   10089    +4     
  Misses      2359    2359           
  Partials     213     213           
Impacted Files Coverage Δ
bridge/opentracing/bridge.go 63.7% <100.0%> (+0.2%) ⬆️
sdk/trace/batch_span_processor.go 80.2% <0.0%> (-1.8%) ⬇️
exporters/jaeger/jaeger.go 91.1% <0.0%> (+0.8%) ⬆️
sdk/metric/periodic_reader.go 91.3% <0.0%> (+1.2%) ⬆️

Copy link
Contributor

@MadVikingGod MadVikingGod left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It looks like this assumes that if the format is HTTPHeaders and we fall back to the TextMapCarrier, the backing type will do the appropriate URL encoding. I would suggest we document this edge case.

.gitignore Outdated Show resolved Hide resolved
@yurishkuro
Copy link
Member Author

yurishkuro commented Feb 6, 2023

It looks like this assumes that if the format is HTTPHeaders and we fall back to the TextMapCarrier, the backing type will do the appropriate URL encoding. I would suggest we document this edge case.

@MadVikingGod it's a good question. I don't see how OTEL handles this in general since it does not have a dedicated HTTP propagator. In OT it was the responsibility of the Tracer to encode values for http before passing them to the carrier. While it could be made a responsibility of the carrier in OTEL, I don't see it being done in OTEL. This is how net/http instrumentation does injection:

        r = r.WithContext(ctx)
        span.SetAttributes(semconv.HTTPClientAttributesFromHTTPRequest(r)...)
        t.propagators.Inject(ctx, propagation.HeaderCarrier(r.Header))

Here propagation.HeaderCarrier is a type alias for the http.Header and does not do any special encoding of the values (and neither does http.Header afaik). So at least in this respect my PR does not give a different behavior vs. what already happens.

Where does the encoding of values happen in OTEL?

@MadVikingGod
Copy link
Contributor

http.Header.Set() does canonicalize keys, but it does look like it leaves values alone.

@yurishkuro
Copy link
Member Author

can this be merged?

@MrAlias MrAlias merged commit 6897591 into open-telemetry:main Feb 14, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[opentracing] OT Bridge does not work with OT gRPC instrumentation
5 participants