-
Notifications
You must be signed in to change notification settings - Fork 857
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
feat(SugaredTracer): add draft of sugaredTracer #3317
feat(SugaredTracer): add draft of sugaredTracer #3317
Conversation
Codecov Report
Additional details and impacted files@@ Coverage Diff @@
## main #3317 +/- ##
==========================================
+ Coverage 90.39% 92.19% +1.80%
==========================================
Files 114 336 +222
Lines 2363 9512 +7149
Branches 527 2016 +1489
==========================================
+ Hits 2136 8770 +6634
- Misses 227 742 +515
|
Thanks for moving this over |
Setting aside the name for a moment -- do we feel that this accomplishes the goal of making it easy to create auto-closing spans as an end-user? If so, then I'd love to try and drive this forward. |
I have brought this up during the SIG meeting and there hasn't been a negative reaction so far. |
A discussion requesting features that can be solved by this PR: #2477. |
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.
Other than the function name this generally looks good to me
api/src/trace/SugaredTracer.ts
Outdated
* return a new SugaredTracer created from the supplied one | ||
* @param tracer | ||
*/ | ||
export function wrapTracer(tracer: Tracer): SugaredTracer { |
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.
Why this function instead of a user just newing up their own sugared tracer?
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.
My thought has been that we can inject easier logic without touching the constructor itself, but I have no strong feelings regarding this.
api/src/trace/SugaredTracer.ts
Outdated
* @param arg2 | ||
* @param arg3 | ||
*/ | ||
function massageParams<F extends (span: Span) => ReturnType<F>>(arg: SugaredSpanOptions | F, |
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 can't think of a good name for this but the existing name doesn't describe at all what it does. Maybe something like getVariadicParams
?
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.
IMO the get
suggests that we are retrieving the params somewhere from. What do you think about processParams
or normalizeParams
?
Assuming names are agreed upon and look good, what all else would be needed to get this accepted and merged? |
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.
Generally LGTM % nits.
I'm sorry but this has to be held until the conversation in open-telemetry/opentelemetry-specification#2968 is resolved |
This PR is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 14 days. |
Still waiting for the outcome... |
FWIW I believe that should that spec PR get merged, this is still considered valid as per spec:
|
I have tried it out but I have occasions were the arguments is |
Can you elaborate what function you are referring too? There is no function which has |
@secustor Sorry for being unclear I was referring to the Also any particular reason why it's not part of the class itself? |
Idea is to allow usage for potential different classes. |
This PR is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 14 days. |
@dyladan @legendecas WDYT about merging this as the specification change hasn't been merged? If you would, I will fix up this PR. |
Sorry for the late response. Regarding the spec changes has been stalled, I'd suggest publishing the sugar tracer in a separate package (e.g. @opentelemetry/api-extension, or @opentelemetry/api-incubator). This is how the Java implementation is doing: https://github.com/open-telemetry/opentelemetry-java/blob/main/extensions/incubator/src/main/java/io/opentelemetry/extension/incubator/trace/ExtendedTracer.java. In this way, I believe we don’t have to wait for the specification changes and avoid conflicts with future spec APIs. |
We have also discussed another approach recently in the SIG meeting: using different entry points in the API package for experimental features, see #3827 (comment) |
Can someone assist me with this |
93de38e
to
98d3036
Compare
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.
Thank you for working on this!
I believe we can still mitigate the api-eol failure as suggested as we'd like to keep runtime support in the API package.
Since it is approved, can we merge? |
* feat(api): add experimental package and SugaredTracer * tests(api/experimental): add tests * fix: packages.json exports * move export into experimental package * add additional tests * fix: do not use catch and finally for compatibility with Node 8 --------- Co-authored-by: Chengzhong Wu <legendecas@gmail.com>
Which problem is this PR solving?
Early draft of a SugaredTracer, intended as basis for discussions and implementation ideas.
Ref #3250
cc @cartermp
cd @legendecas
Supersedes open-telemetry/opentelemetry-js-api#173
Signed-off-by: secustor sebastian@poxhofer.at
Short description of the changes
Type of change
Please delete options that are not relevant.
How Has This Been Tested?
Please describe the tests that you ran to verify your changes. Provide instructions so we can reproduce. Please also list any relevant details for your test configuration
Checklist: