-
Notifications
You must be signed in to change notification settings - Fork 893
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
Make clear the propagated/non-recording span concept needs no type. #1131
Make clear the propagated/non-recording span concept needs no type. #1131
Conversation
I just don't get why any of this is needed. I think I'd be fine with not using a separate context key if none of this was added to the API spec and the spec of the extractor simply said a Span should be created from propagated trace context with Edit: From #1124 it appears why I don't get why this is needed is I was missing the need for making this |
Also, from a performance perspective, a non-recording span can be implemented more efficiently and lightweight than a full span. |
And there is also no other API to create a non-recording span (except if you muck around with samplers maybe). |
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 much easier for me to understand, thanks
Co-authored-by: Armin Ruech <[email protected]>
@open-telemetry/specs-approvers Please review. The more eyes/approvals, the better ;) |
…pen-telemetry#1131) * Make clear the propagated /non-recording span concept needs no type. * Update specification/trace/api.md Co-authored-by: Armin Ruech <[email protected]> Co-authored-by: Armin Ruech <[email protected]>
Fixes #1087, closes #1124, closes #1125
Changes
Makes clear that the non-recording span / propagated Span has no semantic meaning and should not be a new public type.