-
Notifications
You must be signed in to change notification settings - Fork 821
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
refactor: simplify b3 options #2054
Conversation
Codecov Report
@@ Coverage Diff @@
## main #2054 +/- ##
=======================================
Coverage 93.03% 93.03%
=======================================
Files 153 154 +1
Lines 5972 5975 +3
Branches 1246 1246
=======================================
+ Hits 5556 5559 +3
Misses 416 416
|
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.
May want to add upgrade notes and flag as breaking due to export removals
api.propagation.setGlobalPropagator(new B3MultiPropagator()); | ||
``` | ||
|
||
### CompositePropagator |
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.
is CompositePropagator not allowed anymore, as with regards to possibility I think it should still be possible ?
const api = require('@opentelemetry/api');
const { B3Propagator } = require('@opentelemetry/propagator-b3');
api.propagation.setGlobalPropagator(
new CompositePropagator({
propagators: [
new B3Propagator(),
new B3Propagator({ injectEncoding: B3InjectEncoding.MULTI_HEADER })
],
})
);
?
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.
By default it already extracts both. Is there a usecase where we need to also inject both? Of course you can always use a composite just like you can with any propagator, but keeping it documented feels unnecessary for such a niche usecase.
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.
not sure, but we had this before so if anyone is using such case it might be hard to understand how it should be done now after these changes
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.
It's still possible. I don't think it's a common use case, but we can document it.
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.
Looks there are no functionality changes? Just docs and moving some constants around into their own file.
@obecny looks like you added breaking label but there is no functionality actually changed here. |
we have now |
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 think we should also update all usage replacing B3Multi and B3Single with new class
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.
and lastly we should add info to README.md section Upgrade Guidelines
showing how to use B3 now with single and multi
B3SinglePropagator -> new B3Propagator({ injectEncoding: B3InjectEncoding.MULTI_HEADER })
etc.
There is no new class. We already have |
Am I the only one that see that both classes |
Oh I see. @mwear was that an intended change? |
I think it is exactly what changed, end users should always use multi b3 propagator and configure it to use only single or only multi headers if they dont want both |
Yeah, that was the intention of this PR and a result of a discussion from the spec repo, namely this comment: open-telemetry/opentelemetry-specification#1562 (comment). We had a number of ways to configure b3, but we probably want to steer users towards using the I'll address upgrade notes and other docs concerns. |
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.
lgtm, thx for changes
Which problem is this PR solving?
Short description of the changes
Based on the discussion on open-telemetry/opentelemetry-specification#1562 we always want to extract both b3 single and multi header formats. There really isn't a use case for extracting the formats individually, so this PR reduces the b3 surface area by not exporting the
B3SinglePropagator
orB3MultiPropagator
.