The current Python SDK metrics/log telemetry path appears to set span_id from the propagation context even when there is no active span, which does not match the metrics spec. In Scope.apply_to_telemetry, telemetry gets trace_id and span_id from Scope.get_trace_context whenever a telemetry item does not already define them. When there is no active span, get_trace_context() falls back to the propagation context and returns propagation_context.span_id. That span_id is lazily generated in PropagationContext.span_id, so it can exist even when the metric was not emitted during an active span.
The metrics spec says the opposite split: trace_id is required and must come from the current propagation context, while span_id is optional and should be the span ID of the span that was active when the metric was emitted. That means propagation-context fallback is correct for trace_id, but not for span_id when no span is active. For comparison, the JavaScript SDK follows that model: metrics use propagation context only for trace_id in packages/core/src/metrics/internal.ts, and its default propagation context does not synthesize a spanId in packages/core/src/scope.ts or packages/core/src/utils/tracing.ts.
This issue is to investigate whether the Python SDK telemetry path should be adjusted to keep propagation-context fallback for trace_id while only attaching span_id when an active span exists, or whether the current broader behavior is intentional and the spec should be revisited instead.
The current Python SDK metrics/log telemetry path appears to set
span_idfrom the propagation context even when there is no active span, which does not match the metrics spec. InScope.apply_to_telemetry, telemetry getstrace_idandspan_idfromScope.get_trace_contextwhenever a telemetry item does not already define them. When there is no active span,get_trace_context()falls back to the propagation context and returnspropagation_context.span_id. Thatspan_idis lazily generated inPropagationContext.span_id, so it can exist even when the metric was not emitted during an active span.The metrics spec says the opposite split:
trace_idis required and must come from the current propagation context, whilespan_idis optional and should be the span ID of the span that was active when the metric was emitted. That means propagation-context fallback is correct fortrace_id, but not forspan_idwhen no span is active. For comparison, the JavaScript SDK follows that model: metrics use propagation context only fortrace_idinpackages/core/src/metrics/internal.ts, and its default propagation context does not synthesize aspanIdinpackages/core/src/scope.tsorpackages/core/src/utils/tracing.ts.This issue is to investigate whether the Python SDK telemetry path should be adjusted to keep propagation-context fallback for
trace_idwhile only attachingspan_idwhen an active span exists, or whether the current broader behavior is intentional and the spec should be revisited instead.