Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
[core] - Scope down OpenTelemetry interfaces #17730
[core] - Scope down OpenTelemetry interfaces #17730
Changes from 8 commits
61e1427
92b05a2
9eb638b
35d018c
efdb0eb
ec84f87
1d47583
b023fad
7eedf67
b5b5c84
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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.
This is really just
Error | string
- for our usecase we can just sayError
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.
These are all used in test code only (but see my callout about EH / SB in summary) so I got rid of them and had the test code updated to pull in from @azure/test-utils
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 love to see the simplification!
Could you lay out what the next sequence of steps you think are? e.g. will Span eventually be a re-export of OT? Do we need to have some minimal interface for it ourselves?
Same with
context
- can we avoid having SDKs interact with context directly or even have to know about 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.
Sure!
Assumption: EventHubs and ServiceBus are ok taking a direct dependency on @opentelemetry/api (I still have to get confirmation on that and will reach out offline)
I should note though that at the end of the day we can remove what we can but we are likely stuck with some of these interfaces for the time being... they've been here for a while, packages have taken dependencies on them, and so we can't unfortunately pull the rug from under them anymore.
Must stay
I'd love to remove all of these, but these are the ones that will be really hard to tease out at this point
Still investigating if these can go
Longer term (post GA)
What do you think?
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.
Figured I'll expand what those are:
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.
This is an interesting point. Since tracing is heavily dependent on OpenTelemetry, I think it's reasonable to match their support level for TS. So if they only work on TS 3.8+, I think it's fair that we are the same (for tracing interfaces, that is.) I don't want to be in the business of trying to monkeypatch their compat story.
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.
Also I'm curious what the blocker is from re-exporting the OT shapes? Why does our definition of Span vs theirs make a meaningful difference to TS?
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.
There's two issues that I am aware of and I believe both are related to
import type
andexport type
being used in OTel's APIThe first is that our version of API Extractor (7.7.x) does not support them so we end up with these warnings on every package when I try to re-export any APIs directly from OTel:
See #9410 and #13557 as related issues (and of course upgrading API Extractor is not free because of how it handles name collision in later versions, see #17702 for an example)
The second is less clear to me - I'm hopeful @richardpark-msft or @chradek remember why #14618 was needed? That looks like where we removed the re-exports and redeclared the types
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.
Let's just call this
Date
- we don't need to support everything and can assume the caller can make any conversions neeeded. We can always expand later.