The change restricts error cleanup to only legacy `Span` instances with `isinstance(span, Span)`, but when span streaming mode is enabled, `get_start_span_function()` returns `StreamedSpan` instances instead. When an exception occurs, `_capture_exception()` calls `set_span_errored()` which sets `StreamedSpan.status` to `SpanStatus.ERROR` (value "error"). Even if the isinstance check were extended to include `StreamedSpan`, the status comparison `span.status == SPANSTATUS.INTERNAL_ERROR` (value "internal_error") would fail because `StreamedSpan` uses a different status value. This causes errored spans to not be properly closed via `__exit__` in streaming mode.

The change restricts error cleanup to only legacy `Span` instances with `isinstance(span, Span)`, but when span streaming mode is enabled, `get_start_span_function()` returns `StreamedSpan` instances instead. When an exception occurs, `_capture_exception()` calls `set_span_errored()` which sets `StreamedSpan.status` to `SpanStatus.ERROR` (value "error"). Even if the isinstance check were extended to include `StreamedSpan`, the status comparison `span.status == SPANSTATUS.INTERNAL_ERROR` (value "internal_error") would fail because `StreamedSpan` uses a different status value. This causes errored spans to not be properly closed via `__exit__` in streaming mode.

The `@ensure_integration_enabled` decorator was removed from `_wrap_task_call` but `@wraps(f)` was not added as a replacement. The code comment on lines 392-396 explicitly warns: "if we ever remove the @ensure_integration_enabled decorator, we need to add @functools.wraps(f) here" because celery-once looks at the method's name. Without this, the wrapper function's `__name__` will be `_inner` instead of the original function's name, breaking celery-once compatibility.

In `_sentry_execute_command`, spans are entered via `__enter__()` but exited only in the happy path. If `old_execute_command` raises an exception, `db_span.__exit__()` and `cache_span.__exit__()` are never called. This causes spans to remain on the scope stack, leading to orphaned spans and potential memory leaks. The `StreamedSpan.__exit__` method also sets the span status to ERROR on exceptions, which won't happen here.

In `_sentry_execute_command`, spans are entered via `__enter__()` but exited only in the happy path. If `old_execute_command` raises an exception, `db_span.__exit__()` and `cache_span.__exit__()` are never called. This causes spans to remain on the scope stack, leading to orphaned spans and potential memory leaks. The `StreamedSpan.__exit__` method also sets the span status to ERROR on exceptions, which won't happen here.

In `_sentry_execute_command`, spans are entered via `__enter__()` but exited only in the happy path. If `old_execute_command` raises an exception, `db_span.__exit__()` and `cache_span.__exit__()` are never called. This causes spans to remain on the scope stack, leading to orphaned spans and potential memory leaks. The `StreamedSpan.__exit__` method also sets the span status to ERROR on exceptions, which won't happen here.

The `getresponse` function calls `span.finish()` at line 183 regardless of the span type. For `StreamedSpan` instances (when span streaming is enabled), `finish()` is deprecated and emits a warning via `warnings.warn()` before calling `end()`. This means every HTTP request made through stdlib's HTTPConnection will generate a deprecation warning when using the new span streaming mode. Users will see noisy warnings in their logs/stderr for normal SDK operation.

The `getresponse` function calls `span.finish()` at line 183 regardless of the span type. For `StreamedSpan` instances (when span streaming is enabled), `finish()` is deprecated and emits a warning via `warnings.warn()` before calling `end()`. This means every HTTP request made through stdlib's HTTPConnection will generate a deprecation warning when using the new span streaming mode. Users will see noisy warnings in their logs/stderr for normal SDK operation.

In the `on_parse` method, when span streaming is enabled, the span is created without the `parent_span=self.graphql_span` argument (line 261), unlike the `on_validate` method which correctly passes it (line 240). Without the explicit parent, the parsing span will be parented to whatever is currently on the scope, which may result in incorrect span hierarchy where the parsing span is not properly nested under the graphql_span.

In the `on_parse` method, when span streaming is enabled, the span is created without the `parent_span=self.graphql_span` argument (line 261), unlike the `on_validate` method which correctly passes it (line 240). Without the explicit parent, the parsing span will be parented to whatever is currently on the scope, which may result in incorrect span hierarchy where the parsing span is not properly nested under the graphql_span.

When `self._span` is a `NoOpStreamedSpan`, the check `isinstance(self._span, StreamedSpan)` returns `True` (since `NoOpStreamedSpan` inherits from `StreamedSpan`). However, `NoOpStreamedSpan.__init__` sets `self.segment = None`. This causes `self._span.segment.set_name(name)` to raise `AttributeError: 'NoneType' object has no attribute 'set_name'`. Any call to `scope.set_transaction_name()` while a `NoOpStreamedSpan` is active will crash.

In `_update_sample_rate_from_segment`, `str(span.sample_rate)` is called unconditionally when `baggage` is not None. However, `span.sample_rate` can be `None` in several scenarios (tracing disabled, sampled already set, invalid sample rate). This results in `"None"` being stored in the baggage's `sentry_items["sample_rate"]`, which would propagate incorrect sampling data to downstream services. The equivalent code in `start_transaction` (line 1116) correctly checks `if transaction.sample_rate is not None` before updating baggage.

In `_update_sample_rate_from_segment`, `str(span.sample_rate)` is called unconditionally when `baggage` is not None. However, `span.sample_rate` can be `None` in several scenarios (tracing disabled, sampled already set, invalid sample rate). This results in `"None"` being stored in the baggage's `sentry_items["sample_rate"]`, which would propagate incorrect sampling data to downstream services. The equivalent code in `start_transaction` (line 1116) correctly checks `if transaction.sample_rate is not None` before updating baggage.

At line 418-419, when `self.sampled is None`, the code logs 'Discarding transaction without sampling decision' but does not return. Unlike the legacy implementation in `tracing.py:1035-1038` which returns after this warning, this code continues execution, sets `_finished = True` at line 437, and also fails to record the lost event metric. This means spans with no sampling decision are silently lost without proper telemetry tracking, and the log message is misleading.

The `span_id` and `trace_id` properties in `NoOpStreamedSpan` return hardcoded "000000" values. When a `NoOpStreamedSpan` is active as `scope.span`, calling `sentry_sdk.get_traceparent()` returns "000000-000000-0" instead of falling back to the propagation context. This can cause invalid trace headers to be propagated to downstream services, breaking distributed tracing continuity.

The `is_ignored_span` function initializes `name_matches` and `attributes_match` to `True`, then only overwrites them if the rule dict contains 'name' or 'attributes' keys respectively. An empty dict rule `{}` in `ignore_spans` config would match every span because both variables remain `True`. This could cause silent data loss if a user accidentally includes an empty dict in their config.

Line 500 asserts `segment1["trace_id"] == segment1["trace_id"]` which is always true (comparing a value to itself). The test `test_sibling_segments` intends to verify that sibling segments share the same trace_id, so the assertion should be `segment1["trace_id"] == segment2["trace_id"]`. This bug means the test doesn't actually verify the intended behavior, and a regression could go undetected.