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.

Line 500 contains `assert segment1["trace_id"] == segment1["trace_id"]` which compares the value to itself and will always pass. Based on the test name `test_sibling_segments` and the corresponding `test_sibling_segments_new_trace` test which asserts `segment1["trace_id"] != segment2["trace_id"]`, the intention here is to verify that sibling segments share the same trace_id when `new_trace()` is not called. The assertion should be `segment1["trace_id"] == segment2["trace_id"]`.