[Feature]: Add export_unsampled option to BatchSpanProcessor (opt-in export of recording but unsampled spans)

[agent-adam]

Related Problems?

By default, the Rust SDK exports only sampled spans. There is no way to export recording but unsampled spans. This makes it difficult to:

• Generate accurate span-to-metrics pipelines (RED metrics, error ratios, SLO burn).
• Feed tail-samplers in a Collector with complete input, while still limiting upstream egress.

Other SDKs have moved forward with this support:

• Spec change: opentelemetry-specification#2986
• Java SDK:
  • #4990 — Proposal to forward non-sampled spans
  • #6057 — Merged implementation adding setExportUnsampledSpans(true)

Currently, the Rust SDK even fixed a bug to stop exporting unsampled spans (#871), so there is no supported opt-in path today.

Describe the solution you'd like:

I’d like the API to expose an opt-in flag on BatchSpanProcessor (and plumb it through to exporters) that enables exporting recording-but-unsampled spans.

Example sketch:

let exporter = opentelemetry_otlp::new_exporter().tonic().with_endpoint("http://localhost:4317");
let bsp = BatchSpanProcessor::builder(exporter, runtime)
    .with_export_unsampled(true) // <-- new opt-in
    .build();

Expected behavior:

• Default remains false (only sampled spans exported).
• When true, spans with is_recording == true but TraceFlags::SAMPLED == false are also exported.
• Exporters may mark these as unsampled so downstream can distinguish them.

Considered Alternatives

No response

Additional Context

No response

Tip

_{React with 👍 to help prioritize this issue. Please use comments to provide useful context, avoiding +1 or me too, to help us triage it. Learn more here.}

[jmacd]

This is a gap in the OpenTelemetry specification.

https://github.com/open-telemetry/opentelemetry-specification/issues/2986

I support specification work on this, especially if it will help solve the issue here.