-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
baggage: Add NewMemberRaw and NewKeyValuePropertyRaw #4804
Conversation
Codecov ReportAttention:
Additional details and impacted files@@ Coverage Diff @@
## main #4804 +/- ##
=======================================
- Coverage 82.3% 82.3% -0.1%
=======================================
Files 226 226
Lines 18392 18401 +9
=======================================
Hits 15148 15148
- Misses 2963 2969 +6
- Partials 281 284 +3
|
@yurishkuro PTAL |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would suggest combining this change with w3c propagator change and moving all encoding responsibilities into the propagator
I don't think it actually fixes the main ticket - a complete fix would be to change all propagators to use the new xxxRaw methods when accessing baggage. |
Is there any other place where the propagators should use the new methods? I have not found any other usages. Take notice that the baggage propagator uses |
that's precisely the thing that makes no sense to me. W3C baggage format is different from Jaeger baggage format, so encode/decode functions must exist in the propagators, not in the shared baggage layer, and propagators should only read/write raw values, not expect the shared baggage layer to do any encoding for them. |
That ship has sailed 🤷 We can copy paste the encoding/decoding code, but I see no big sense in doing that as I see no big value in code duplication. Rather the opposite as if we find an improvement or bug in the encoding/decoding code then we would have to apply it in two places. I want to avoid making breaking changes in |
Why? Propagator calling Parse/String is implementation detail of the propagator, it can be changed. Same as with the non-raw accessors the Parse function can be deprecated. |
It would lead to code duplication as mentioned before. I think it would be less controversial if this PR only introduces new function as proposed #4804 (comment). The deprecation can be done in a separate PR. |
Co-authored-by: Tyler Yahn <MrAlias@users.noreply.github.com>
Towards #3685
Related to open-telemetry/opentelemetry-specification#3801
Add
NewMemberRaw
andNewKeyValuePropertyRaw
which does not require-precent encoding.Add a notice to
NewMember
andNewKeyValueProperty
about the new functions.The bridge now uses
NewMemberRaw
to fix #3685.The alternative fix (quickfix) for the OpenTracing Bridge would be to precent-encode the value in
func (c *bridgeSpanContext) setBaggageItem(restrictedKey, value string)
. However, I decided to add new functions, because of open-telemetry/opentelemetry-specification#3801. I also feel that the new functions are more usable.Initially, I changed the bevavior of
NewMember
andNewKeyValuePropertyRaw
, but I think that it would be safer and more user-friendly to make the change in a backwards-compatible manner.This PR contains also breaking behavioral change:
Property.Value
now returns a vanilla string instead of a percent-encoded value.This is what
Member.Value
returns right now so it makes the API consistent.I would rather say that it is a bugfix than a change, but I prefer to have it listed in "changed" in the changelog.