If an exception occurs after `transaction` is assigned (line 332) but before `span_ctx` is assigned (line 339), `capture_internal_exceptions()` swallows the exception. Since `transaction is None` check (line 365) passes and `span_ctx` is never initialized, line 368 `with span_ctx:` raises `UnboundLocalError`. This can happen if `set_origin()`, `set_source()`, or `set_op()` raises an exception.

If an exception occurs after `transaction` is assigned (line 332) but before `span_ctx` is assigned (line 339), `capture_internal_exceptions()` swallows the exception. Since `transaction is None` check (line 365) passes and `span_ctx` is never initialized, line 368 `with span_ctx:` raises `UnboundLocalError`. This can happen if `set_origin()`, `set_source()`, or `set_op()` raises an exception.

If an exception occurs after `transaction` is assigned (line 332) but before `span_ctx` is assigned (line 339), `capture_internal_exceptions()` swallows the exception. Since `transaction is None` check (line 365) passes and `span_ctx` is never initialized, line 368 `with span_ctx:` raises `UnboundLocalError`. This can happen if `set_origin()`, `set_source()`, or `set_op()` raises an exception.

In span streaming mode, the span is created via `sentry_sdk.traces.start_span()` but never started (no `.start()` call or context manager entry). When `finish()` is called in the finally block, it attempts to access `_context_manager_state` which was never set because `__enter__` was never called. This causes an `AttributeError` that is silently caught by `capture_internal_exceptions()`, resulting in the span never being properly sent to Sentry.

In span streaming mode, the span is created via `sentry_sdk.traces.start_span()` but never started (no `.start()` call or context manager entry). When `finish()` is called in the finally block, it attempts to access `_context_manager_state` which was never set because `__enter__` was never called. This causes an `AttributeError` that is silently caught by `capture_internal_exceptions()`, resulting in the span never being properly sent to Sentry.

The `_estimate_size` method uses integer division by 1024 (`// 1024`), which means any span serializing to less than 1024 characters will return 0. Typical spans are likely to be a few hundred bytes, so most will contribute 0 to `_running_size`, causing the size-based flush threshold (`MAX_KB_BEFORE_FLUSH`) to effectively never trigger. The buffer could accumulate significant memory before the count-based flush (1000 spans) kicks in.

The `_estimate_size` method uses integer division by 1024 (`// 1024`), which means any span serializing to less than 1024 characters will return 0. Typical spans are likely to be a few hundred bytes, so most will contribute 0 to `_running_size`, causing the size-based flush threshold (`MAX_KB_BEFORE_FLUSH`) to effectively never trigger. The buffer could accumulate significant memory before the count-based flush (1000 spans) kicks in.

The `_set_status` function ignores the `status` parameter when using StreamedSpan and always sets `SpanStatus.ERROR`. This is incorrect when called with `"aborted"` (for Celery control flow exceptions like Retry, Ignore, Reject), which are not actual errors. The result is that legitimate task retries and intentional ignores will be incorrectly flagged as errors in Sentry traces when using span streaming mode.

The `_set_status` function ignores the `status` parameter when using StreamedSpan and always sets `SpanStatus.ERROR`. This is incorrect when called with `"aborted"` (for Celery control flow exceptions like Retry, Ignore, Reject), which are not actual errors. The result is that legitimate task retries and intentional ignores will be incorrectly flagged as errors in Sentry traces when using span streaming mode.

The `@ensure_integration_enabled(CeleryIntegration, f)` decorator was removed from `_inner` but the required `@wraps(f)` decorator was not added. The comment on lines 395-399 explicitly warns: "functools.wraps is important here because celery-once looks at this method's name... if we ever remove the @ensure_integration_enabled decorator, we need to add @functools.wraps(f) here." Without `@wraps(f)`, the wrapped function will have the name `_inner` instead of the original function name, breaking celery-once and potentially other tools that inspect function metadata.

The async httpx implementation uses simple string concatenation to append baggage headers (line 190: `request.headers[key] += "," + value`), while the sync implementation uses `add_sentry_baggage_to_headers()` which strips existing Sentry baggage items first. This inconsistency can lead to duplicate or conflicting Sentry baggage items being sent in outgoing requests when using the async client, potentially causing issues with distributed tracing.

On line 220, when creating a StreamedSpan with a parent StreamedSpan, the code calls `sentry_span.set_origin("origin")` with a hardcoded string literal instead of `self.origin`. All other code paths correctly use `self.origin` (e.g., lines 225, 235, 240). This causes spans created via the Rust tracing integration in streaming mode with a parent span to have incorrect origin metadata, breaking span attribution and filtering.

In `on_parse()`, when span streaming is enabled, the parsing span is created without passing `parent_span=self.graphql_span`, unlike `on_validate()` which correctly passes it. This will cause the parsing span to be orphaned from the graphql_span tree, resulting in incorrect span hierarchy and potentially broken trace visualization in Sentry.

In `on_parse()`, when span streaming is enabled, the parsing span is created without passing `parent_span=self.graphql_span`, unlike `on_validate()` which correctly passes it. This will cause the parsing span to be orphaned from the graphql_span tree, resulting in incorrect span hierarchy and potentially broken trace visualization in Sentry.

In `SentrySyncExtension.resolve()`, line 354 uses `name="resolving {field_path}"` instead of `name=f"resolving {field_path}"`. This means the span name will literally be "resolving {field_path}" rather than interpolating the actual field path value (e.g., "resolving User.name"). This affects observability and debugging since all resolver spans will have the same unhelpful name.

In `SentrySyncExtension.resolve()`, line 354 uses `name="resolving {field_path}"` instead of `name=f"resolving {field_path}"`. This means the span name will literally be "resolving {field_path}" rather than interpolating the actual field path value (e.g., "resolving User.name"). This affects observability and debugging since all resolver spans will have the same unhelpful name.

In the `is_ignored_span` function, when processing dict rules, both `name_matches` and `attributes_match` default to `True` (lines 1499-1500). If a user provides an empty dict `{}` or a dict without `name` or `attributes` keys in the `ignore_spans` config, the condition `if name_matches and attributes_match` at line 1516 will be true, causing ALL spans to be ignored. The `IgnoreSpansContext` TypedDict allows empty dicts since `total=False` makes both fields optional.