Skip to content

Conversation

@paullegranddc
Copy link
Contributor

Even though all fields are public, because of the #[non_exhaustive] annotation on SpanEventsand SpanLinks, it's not possible to construct instances of these outside of the opentelemetry-sdk crate.

Since they are used in export::SpanData, it is problematic because it means there is no way to create span data containing any events or span links. So there is no way to write tests on how to these fields are processed in external crate that implement the SpanExporter or SpanProcessor traits.

Changes

Add public constructors on SpanEvents and SpanLinks structs.

Merge requirement checklist

  • CONTRIBUTING guidelines followed
  • Unit tests added/updated (if applicable)
  • Appropriate CHANGELOG.md files updated for non-trivial, user-facing changes
  • Changes in public API reviewed (if applicable)

# Changes

Add public constructors on SpanEvents and SpanLinks structs.

# Motivation

Even though all fields are public, because of the `#[non_exhaustive]` annotation on `SpanEvents`and `SpanLinks`, it's not possible to construct instances of these outside of the `opentelemetry-sdk` crate.

Since they are used in `export::SpanData`, it is problematic because it means there is no way to create span data containing any events or span links.
So there is no way to write tests on how to these fields are processed in external crate that implement the SpanExporter or SpanProcessor traits.
@paullegranddc paullegranddc requested a review from a team as a code owner April 18, 2025 11:49
@codecov
Copy link

codecov bot commented Apr 18, 2025

Codecov Report

Attention: Patch coverage is 0% with 12 lines in your changes missing coverage. Please review.

Project coverage is 81.3%. Comparing base (b5d31f1) to head (7b63d41).
Report is 21 commits behind head on main.

Files with missing lines Patch % Lines
opentelemetry-sdk/src/trace/events.rs 0.0% 6 Missing ⚠️
opentelemetry-sdk/src/trace/links.rs 0.0% 6 Missing ⚠️
Additional details and impacted files
@@           Coverage Diff           @@
##            main   #2934     +/-   ##
=======================================
- Coverage   81.3%   81.3%   -0.1%     
=======================================
  Files        126     126             
  Lines      24254   24266     +12     
=======================================
  Hits       19736   19736             
- Misses      4518    4530     +12     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

}

impl SpanLinks {
/// Create a new `SpanLinks` from a list of events and a dropped count
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is it only required for tests?

Copy link
Contributor Author

@paullegranddc paullegranddc Apr 22, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, I need it for tests, but there are definitely wider use cases.
For instance you could imagine span processors or span exporters trying to create "synthetic spans" and put span links and span events on these synthetic spans.

This currently doesn't work, and I can't think of a good rational as to why creating SpanData without span events should not be possible, and not with them.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This currently doesn't work, and I can't think of a good rational as to why creating SpanData without span events should not be possible, and not with them.

It feels like there is one too many negations here. I assume you're saying that if it's possible to create SpanData without SpanLinks and SpanEvents, then it should be possible to create SpanData with them.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wonder if they should not be builders. The reason being that I believe we had intentionally made them non_exhaustive to prevent api breakage but if we go with simply a new that would then potentially require creating a new with breaking changes in the future.
What do you think @cijothomas ?

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well actually I was thinking of closing this PR because I found a way to get around this.

The main reason I was proposing this is I have a function like fn transform_span(s: SpanData) -> InternalSpan with complex business logic which I'd like to write unit tests for.

What I ended up doing is creating a struct mirroring SpanData in my crate, which I can construct. so now I do

pub(crate) struct ExportSpan {
    pub span_context: opentelemetry::trace::SpanContext,
    pub parent_span_id: opentelemetry::trace::SpanId,
    pub span_kind: opentelemetry::trace::SpanKind,
    pub name: Cow<'static, str>,
    pub start_time: SystemTime,
    pub end_time: SystemTime,
    pub attributes: Vec<opentelemetry::KeyValue>,
    pub dropped_attributes_count: u32,
    pub events: Vec<Event>,
    pub dropped_event_count: u32,
    pub links: Vec<opentelemetry::trace::Link>,
    pub dropped_links_count: u32,
    pub status: opentelemetry::trace::Status,
    pub instrumentation_scope: opentelemetry::InstrumentationScope,
}

fn export_span(s: SpanData) -> ExportSpan; // 1:1 mapping, no tests needed
fn transform_span(s: ExportSpan) -> InternalSpan; // complex logic, but I can create ExportSpan structs for tests

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants