Skip to content
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

Disallow new Span() #3597

Closed
dyladan opened this issue Feb 8, 2023 · 5 comments
Closed

Disallow new Span() #3597

dyladan opened this issue Feb 8, 2023 · 5 comments
Assignees
Labels
bug Something isn't working never-stale priority:p4 Bugs and spec inconsistencies which do not fall into a higher prioritization triage:accepted This feature has been accepted

Comments

@dyladan
Copy link
Member

dyladan commented Feb 8, 2023

Currently it is possible to call new Span(). We should make the constructor private to disallow this.

Current test usages:

Possible additional goals:

  • do not use a class for span (improve minification)
  • create test utility library
@dyladan dyladan added this to the OpenTelemetry SDK 2.0 milestone Feb 8, 2023
@dyladan dyladan added bug Something isn't working never-stale labels Feb 8, 2023
@dyladan dyladan added the priority:p4 Bugs and spec inconsistencies which do not fall into a higher prioritization label Feb 22, 2023
@dyladan dyladan added triage and removed triage labels Sep 27, 2023
@pichlermarc pichlermarc added the triage:accepted This feature has been accepted label Oct 4, 2023
@JamieDanielson
Copy link
Member

Note: To do this, we can make Span private and for TypeScript we should be able to access with obj[“somePrivateProperty”]

@pichlermarc
Copy link
Member

We may also be able to convert uses of Span to ReadableSpan wherever interfaces expect a ReadableSpan instead of an actual SDK span.

@david-luna
Copy link
Contributor

Couple of questions:

  • it should be no problem to leave usage of new Span in sdk-trace-base tests right?
  • should sdk-trace-base export the Span interface from @opentelemetry/api rather than the Span class?

@pichlermarc
Copy link
Member

  • it should be no problem to leave usage of new Span in sdk-trace-base tests right?
  • should sdk-trace-base export the Span interface from @opentelemetry/api rather than the Span class?

Hmm, though questions.

I think the underlying goal should maybe rather be: don't export the Span class from @opentelemetry/sdk-trace-base at all, instead export an interface SdkSpan extends ReadableSpan, APISpan (this may need changes to ReadableSpan to align the spanContext property).

There's nothing wrong with keeping the Span type for internal use in that package, but we should reference the interface wherever possible, not the concrete class.

When going this route, the answer to the questions would be:

it should be no problem to leave usage of new Span in sdk-trace-base tests right?

yes, leaving it is no problem

should sdk-trace-base export the Span interface from @opentelemetry/api rather than the Span class?

Yes, wherever this fulfills the goals of the interface.

An API span is not readable. That's so that users don't use attributes they added to a span in their business logic to convey information, which makes a registered Otel SDK required for their app to function, but business logic should not be impacted, whether you have an OTel SDK registered or not.

In some SDK interfaces, the Span is readable on purpose though. SpanProcessor is an example - you need to be able to read the span to process it. We should provide access to the minimum interface to get the job done 🙂

@david-luna
Copy link
Contributor

@pichlermarc I think this one can be closed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working never-stale priority:p4 Bugs and spec inconsistencies which do not fall into a higher prioritization triage:accepted This feature has been accepted
Projects
None yet
Development

No branches or pull requests

4 participants