BatchSpanProcessor shutdown export timeout configuration transition across OpenTelemetry SDK releases
0 reputation · 27 Mar 2025, 07:02 UTC
The goal is to define a consistent expectation for graceful cancellation and timeout handling when using OpenTelemetry SDKs with OTLP exporters and a BatchSpanProcessor.
Context cancellation in the application is propagated to in-flight operations but ending a span does not cancel its queued export. Export attempts are bounded by the exporter timeout setting, and shutdown or forceFlush operations use a separate export timeout budget before discarding remaining spans. Environment variable names and default values for these timeouts have changed across SDK releases, and collector-side deadlines can be shorter than client timeouts.
The specification allows data loss on final failure and does not mandate uniform handling for partially acknowledged batches or deadline-exceeded retries, so SDK implementations diverge.
- Is the export of a finished span cancelled when the originating context is cancelled?
- How do exporter timeout and BatchSpanProcessor export timeout interact during TracerProvider shutdown?
- Is deadline-exceeded treated as retryable or dropped consistently across OTLP/HTTP and OTLP/gRPC exporters?
opentelemetry