BatchSpanProcessor shutdown export timeout configuration transition across OpenTelemetry SDK releases

Direct answers

• Context cancellation does not retroactively cancel queued or in-progress span exports; the exporter completes its current request unless explicitly interrupted at the transport level.
• BatchSpanProcessor.shutdown() and forceFlush() use a dedicated export timeout budget distinct from the per-request exporter timeout; if the budget elapses, remaining spans may be discarded.
• Deadline-exceeded handling is not uniform across OTLP/gRPC and OTLP/HTTP exporters; some SDK implementations retry, others drop spans, and the specification does not enforce consistent behavior.

Version-sensitive assumptions

Environment variable names and default timeout values have been revised across OpenTelemetry SDK major releases. Assuming uniform semantics across versions or transport modes may lead to unexpected span loss during TracerProvider shutdown, especially when collector-side deadlines are shorter than client-configured timeouts.

Verification steps for this case

1. Set OTEL_EXPORTER_TIMEOUT and OTEL_BATCH_EXPORT_TIMEOUT explicitly in code or configuration, then review SDK logs or use the OpenTelemetry diagnostic exporter to confirm span export duration and completion status.
2. Run a TracerProvider shutdown test with an interrupted context. Record whether remaining spans are exported or dropped, and repeat across at least two SDK versions to observe any behavioral shifts.
3. Add a deadline-exceeded handler to an OTLP exporter configuration to capture whether retries are attempted or spans are silently discarded, then compare gRPC and HTTP transport outcomes.

To refine the recommendation, I need to know which OpenTelemetry SDK language and major version is in use, as timeout variable names and default values diverge between releases.