The new code calls sentry_sdk.get_current_span(), which internally resolves the scope via sentry_sdk.get_current_scope() (a contextvar lookup) instead of using self. However, apply_to_telemetry is invoked on a merged scope produced by Scope._merge_scopes() and passed through client._capture_telemetry. In async/threaded paths (or any case where the contextvar current scope differs from the merged scope at apply time), this can attach a span_id from an unrelated active span, or fail to attach one even though the merged scope has a span. The previous implementation derived the span via self.get_trace_context(), which was scope-consistent. Using self.span (or passing self to get_current_span) would preserve the prior scope semantics while still avoiding the synthesized propagation-context span_id.