The _record function now yields either a Span or StreamedSpan from record_sql_queries, but the callers (e.g., _wrap_connection_method at line 133) pass the span to _set_db_data which calls span.set_data(). The StreamedSpan class does not have a set_data method (only set_attribute), causing an AttributeError at runtime when span streaming mode is enabled. The PR description mentions Django and psycopg cannot be used with span streaming yet, but asyncpg has the same issue and is not mentioned.

Also found at:

• sentry_sdk/integrations/django/__init__.py:644

A print(span) statement on line 486 appears to be leftover debug code in the render_span_tree fixture. This will print span data to stdout during every test that uses this fixture, polluting test output and making CI logs harder to read.

In test_transactions, the span_streaming=True branch only asserts that SPANDATA.SERVER_PORT is not in attributes (line 162), but the span_streaming=False branch asserts both SERVER_ADDRESS and SERVER_PORT are absent (lines 203-204). This inconsistency means the test won't catch regressions where SERVER_ADDRESS is incorrectly included in streamed spans.

Also found at:

• tests/integrations/sqlalchemy/test_sqlalchemy.py:226-243

In test_long_sql_query_preserved, the span_streaming branch accesses spans[0] directly without filtering by origin (line 344). Other similar tests in this file (e.g., test_transactions_no_engine_url at line 284-287) filter spans by sentry.origin == 'auto.db.sqlalchemy' first. If additional spans are captured or ordering changes, this test could fail or pass incorrectly.

In test_no_query_source_if_duration_too_short, the inner if span_streaming: conditional at lines 989-991 is inside the outer else: block (line 962), where span_streaming is always False. The lines 989-991 are dead code that will never execute. This creates confusing test code with excessive branching, even though the test will functionally work correctly.