Repository navigation
Stability : Tracing #977
Description
This is a tracking ticket to cover the steps and have a wholistic view over the Tracing
Multiple members should cross validate, and create issues under the API Milestone for any potential blockers
Stability API
- Gap analysis between tokio tracing
- maybe open a ticket on tokio tracing about aligning on feature?
- Ensure that the features are documented well
- Setup categories could help [Bug]: cargo package features are ill documented #1464
- Validate Matrix Compliance
- TracerProvider
- Trace / Context interaction
- Tracer
- SpanContext
- Span
- Span attributes
- Span linking
- Span events
- Span exceptions
- Sampling
- New Span ID created also for non-recording Spans
- IdGenerators
- SpanLimits (Optional)
- Built-in SpanProcessors implement ForceFlush spec
- Attribute Limits (Optional)
- Fetch InstrumentationScope from ReadableSpan
- Resource - @hdost: I'm not sure if we need this stable, but possibly for Traces to be stable
- Create from Attributes
- Create empty
- Merge (v2)
- Retrieve attributes
- Default value for service.name
- Resource detector interface/mechanism
- Resource detectors populate Schema URL
- Exporters
- Context
- Public API Review
- Validate we don't have too much in the Public API.
- Follow Rust Guidelines - https://rust-lang.github.io/api-guidelines/checklist.html
- DogFood Testing
- Add Performance testing
- Stress tests can provide insight into individual operations
- Integration testing - This can provide insight on the overall performance
- Get a review from the TC
- Release a series of Release candidates (number needed depends on the feedback)
- Mark tracing as stable.
For what is defined as stable for tracing:
We're defining stable as:
- opentelemetry-api tracing
- opentelemetry-sdk tracing
- opentelemetry-jaeger - Jaeger is the most used exporter.(Deprecated aslo)
- opentelemetry-otlp tracing
Zipkin can be stable after GA for tracing.
Docs:
- Add more context for how to choose runtime and why we need runtime SIGINT ignored when using
.install_batch(opentelemetry::runtime::Tokio)#731
Historical #330
Activity
hdost commentedon Feb 28, 2023
@open-telemetry/rust-approvers It's been a couple months like this, I know I'm not as active as the rest of you, but I feel like this wasn't intended.
jtescher commentedon Feb 28, 2023
Yeah we're not currently 1.0, but we're pretty close to stable with tracing could probably commit to a 1.0 at this point and do a 2.0 if we need breaking changes.
hdost commentedon Feb 28, 2023
Perhaps we could add any last tickets to get it to Stable in https://github.com/open-telemetry/opentelemetry-rust/milestone/1
TommyCpp commentedon Feb 28, 2023
Yeah I like the idea to be more organzied on our milestone.
hdost commentedon Mar 2, 2023
I added basically everything related to core SDK functionality to the stabilization, if there's anything that could done after then I'd say feel free to add labels.
I created a few
release:after-stable
release:allowed-for-stable
release:required-for-stable
I modeled them off the Specification Repo's GA related ones.
hdost commentedon Nov 1, 2023
For spec adherence maybe we stick with a specific release for now https://github.com/open-telemetry/opentelemetry-specification/releases/tag/v1.26.0 is the lastest. And then if something comes in then we can can defer for the purpose of getting to stable. Typically this will be better since the spec is only point releases.
darkraider01 commentedon Sep 28, 2026
Edit : I refreshed this, the 0.33 release notes,
docs/traces.md, the current Rust compliance matrix, and the referenced issues/PRs. All three tracing components remain Beta. The old tracker checklist is stale in several places; open issues and-/?matrix entries still need to be classified before calling them Stable blockers.Detailed notes: Tracing Stabilization Tracker
Tracing API
TraceId/SpanIdrepresentation still needs a decision before API freeze.SpanBuilderownership and sampling tradeoffs.FutureExtimplementation is still an open PR.Tracer::enabled()API for early span creation checks #3781: newly filed; Rust does not expose the stableTracer.EnabledAPI. Decide its API shape and whether it is required before Stable. Keep Development-statusTracerConfiguratorwork separate.release:required-for-stable; audit external types in public APIs.Tracing SDK
SpanData#2939 after it lands; feat(sdk): simplify finished span ownership #3741 changes completed-span access and adds live-span read accessors.on_start.Joinablehandle abstraction #3413 is now closed. Decide whether runtime stabilization belongs in the first Stable SDK surface and which design to use.SpanProcessor.OnEndingandRecordException(including extra parameters) missing. Verify those against the Stable spec and either implement them or record an intentional deviation. It also marks exporterForceFlushmissing althoughSpanExporter::force_flush()exists in current code; check the contract and correct the matrix if stale.ParentBasedsampling.Tracing OTLP
experimental-grpc-retryfeature is enabled #3432 also remains open; its panic report depends on the old retry path, so reproduce against current code before deciding whether work remains.?. Refresh those entries from code.Docs / compliance
docs/traces.mdis still marked Work-In-Progress and lists gaps. Review what documentation is required for Stable.release:required-for-stablefor documenting intentional spec deviations.-or?as missing Stable work without checking the current spec and implementation.Decisions still needed
Tracer::enabled()API for early span creation checks #3781 are mandatory before Traces API Stable?Other completed work confirmed in this pass: #3206 partial success, #3621 retries, #3685 sampler branches, and #3725 Hyper response-body timeout enforcement have merged. The 0.33 notes also record compression/config cleanup and request/response limits. #828 is closed, though the tracing guide remains WIP.
Final-sweep addendum — 2026-10-08
TraceState parsing and propagation
tracestateheaders, duplicate keys, invalid key/value pairs, valid Trace Context Level 2 keys, and avoiding propagation of an empty header.release:allowed-for-stableandS-blocked-spec; relate it to feat(trace): support the W3C random trace ID flag #3718 and decide from the chosen spec version.opentelemetry-appender-tracingworkThis tracing-to-logs bridge was not part of the original Stable scope list. If the project intends to include it, #3543 remains an open issue about incorrect event metadata under
experimental_span_attributes. #3498 is an open collision-policy proposal that overlaps with #3497, the Logs SDK attribute-deduplication proposal. Decide these together; neither is currently established as a Traces API/SDK blocker.Other active PRs related to compliance and OTLP
Span::record_error/exception.stacktrace. Check whether it satisfies any or all of the compliance matrixRecordExceptionrows before describing those rows as unaddressed.Stalelabel; describe the live-span-reference and runtime design questions as needing maintainer reactivation/decision, not as actively progressing PRs.Additional open milestone items surfaced
The open milestone/label sweep found older tickets absent from the notes above. Their labels are evidence of prior intent, not proof that each remains a current blocker; verify applicability and either add them to the agreed blocker list or explicitly defer them.
panic=abort). Confirm whether these are still relevant to the current release scope.TracerandSpanBuilder), #1300 (attribute deduplication), #1025 (cancel/drop a span without recording), and #1125 (instrumentation-scope data performance). Classify these as API decisions, optional behavior, or performance work rather than assuming they block Stable.release:allowed-for-stableinclude #890 (SDK autoconfiguration), #857 (decodeOTEL_RESOURCE_ATTRIBUTESvalues), and #1285 (configure tonic gRPC message sizes). Keep these separate from required blockers unless the scope changes.MetricExporterdeadlock; it is metrics work, not a Traces OTLP blocker.