The `get_start_span_function()` returns `sentry_sdk.traces.start_span` when streaming mode is enabled or the current span is a StreamedSpan. However, `sentry_sdk.traces.start_span(name, attributes, parent_span)` has a fixed signature that doesn't accept `op`, `origin`, or other keyword arguments. Integrations (e.g., Anthropic at line 408-412) call the returned function with `op=...`, `name=...`, `origin=...`, which will raise `TypeError: start_span() got unexpected keyword argument 'op'` when streaming mode is enabled, breaking all AI integrations.

The `get_start_span_function()` returns `sentry_sdk.traces.start_span` when streaming mode is enabled or the current span is a StreamedSpan. However, `sentry_sdk.traces.start_span(name, attributes, parent_span)` has a fixed signature that doesn't accept `op`, `origin`, or other keyword arguments. Integrations (e.g., Anthropic at line 408-412) call the returned function with `op=...`, `name=...`, `origin=...`, which will raise `TypeError: start_span() got unexpected keyword argument 'op'` when streaming mode is enabled, breaking all AI integrations.

In the `_wrap_tracer` function, if an exception occurs after `transaction` is assigned (line 332) but before `span_ctx` is assigned (line 337), the code proceeds past the `if transaction is None` check (line 362) and attempts to use `span_ctx` in `with span_ctx:` (line 365). Since `span_ctx` was declared but never assigned, this causes an `UnboundLocalError`. This can happen if `set_origin`, `set_source`, or `set_op` throw an exception, which gets silently caught by `capture_internal_exceptions()`.

In `_wrap_tracer`, `span_ctx` is declared (line 324) but only assigned inside the `capture_internal_exceptions()` block (line 337). If an exception occurs in `transaction.set_origin()`, `transaction.set_source()`, or `transaction.set_op()` after `transaction` is assigned, the check `if transaction is None` (line 362) will pass, but `span_ctx` will be unbound. This causes an `UnboundLocalError` at line 365 when `with span_ctx:` is executed. The user-visible consequence is a runtime crash in Celery task execution when these methods fail.

In streaming mode, `sentry_sdk.traces.start_span()` returns a span that must be used as a context manager (with `with` statement) or explicitly started via `.start()` before calling `.finish()`. The current code creates the span but never enters it, so `_context_manager_state` is uninitialized. When `finish()` calls `__exit__()`, the attempt to access `_context_manager_state` raises an `AttributeError` that is silently caught by `capture_internal_exceptions()`. The span is never sent to Sentry in streaming mode.

In streaming mode, `sentry_sdk.traces.start_span()` returns a span that must be used as a context manager (with `with` statement) or explicitly started via `.start()` before calling `.finish()`. The current code creates the span but never enters it, so `_context_manager_state` is uninitialized. When `finish()` calls `__exit__()`, the attempt to access `_context_manager_state` raises an `AttributeError` that is silently caught by `capture_internal_exceptions()`. The span is never sent to Sentry 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 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.

Every span is serialized twice: once in `_estimate_size()` (line 80) via `_to_transport_format()`, and again during `_flush()` (line 134). For spans with large attribute dictionaries, this doubles the serialization cost. The size estimation could use a simpler heuristic (e.g., counting attribute keys/values) instead of full serialization.

Every span is serialized twice: once in `_estimate_size()` (line 80) via `_to_transport_format()`, and again during `_flush()` (line 134). For spans with large attribute dictionaries, this doubles the serialization cost. The size estimation could use a simpler heuristic (e.g., counting attribute keys/values) instead of full serialization.

Every span is serialized twice: once in `_estimate_size()` (line 80) via `_to_transport_format()`, and again during `_flush()` (line 134). For spans with large attribute dictionaries, this doubles the serialization cost. The size estimation could use a simpler heuristic (e.g., counting attribute keys/values) instead of full serialization.

In the legacy path (line 272), `custom_sampling_context={"asgi_scope": scope}` is passed to `start_transaction`, making it available to `traces_sampler` callbacks. However, the streaming path (lines 225-227) does not call `sentry_scope.set_custom_sampling_context({"asgi_scope": scope})` before `start_span()`. Users with custom `traces_sampler` functions that rely on `asgi_scope` for sampling decisions will not have access to it when using streaming mode.

In the legacy path (line 272), `custom_sampling_context={"asgi_scope": scope}` is passed to `start_transaction`, making it available to `traces_sampler` callbacks. However, the streaming path (lines 225-227) does not call `sentry_scope.set_custom_sampling_context({"asgi_scope": scope})` before `start_span()`. Users with custom `traces_sampler` functions that rely on `asgi_scope` for sampling decisions will not have access to it when using streaming mode.

The `_set_status` function ignores the `status` parameter for `StreamedSpan` instances, always setting `SpanStatus.ERROR`. This means both `_set_status("aborted")` (called for Celery control flow exceptions like Retry, Ignore, Reject) and `_set_status("internal_error")` result in the same ERROR status. For control flow exceptions, this may incorrectly characterize intentional retries/ignores as errors.

The refactored `_set_client_data` function now only sets `redis.is_cluster` when `name` is truthy, whereas the original code always set it unconditionally. This is a behavioral change that will cause the `redis.is_cluster` tag/attribute to be missing from spans when `name` is empty or None, potentially affecting monitoring and debugging capabilities.

In the async `SentryAsyncExtension.resolve()` method, when creating a `StreamedSpan`, the code does not call `span.set_op(OP.GRAPHQL_RESOLVE)` or `span.set_origin(StrawberryIntegration.origin)`. However, the sync `SentrySyncExtension.resolve()` method does include these calls (lines 356-357). This inconsistency means async GraphQL resolvers using span streaming will produce spans without the operation type and origin metadata, resulting in incomplete tracing data in Sentry.

In the async `SentryAsyncExtension.resolve()` method, when creating a `StreamedSpan`, the code does not call `span.set_op(OP.GRAPHQL_RESOLVE)` or `span.set_origin(StrawberryIntegration.origin)`. However, the sync `SentrySyncExtension.resolve()` method does include these calls (lines 356-357). This inconsistency means async GraphQL resolvers using span streaming will produce spans without the operation type and origin metadata, resulting in incomplete tracing data in Sentry.

In the async `SentryAsyncExtension.resolve()` method, when creating a `StreamedSpan`, the code does not call `span.set_op(OP.GRAPHQL_RESOLVE)` or `span.set_origin(StrawberryIntegration.origin)`. However, the sync `SentrySyncExtension.resolve()` method does include these calls (lines 356-357). This inconsistency means async GraphQL resolvers using span streaming will produce spans without the operation type and origin metadata, resulting in incomplete tracing data in Sentry.

On line 418-419, when `self.sampled is None`, a warning "Discarding transaction without sampling decision" is logged, but execution continues. The span may still be captured on line 434 if `self.segment.sampled` is truthy (which shouldn't happen when sampled is None, but creates ambiguous control flow). The log message claims the transaction is being discarded, but there's no `return` to enforce this, unlike the `self.sampled is False` check which properly returns on line 416.

The `populate_from_segment` method sets `sentry_items["transaction"] = segment._name` without first checking if `segment._name` is truthy. The legacy `populate_from_transaction` method checks `transaction.name and transaction.source not in LOW_QUALITY_TRANSACTION_SOURCES` before setting the transaction. This inconsistency could lead to empty string transaction names being propagated in baggage headers.