When span streaming is enabled, record_sql_queries yields a StreamedSpan. The span's _end() method (called via __exit__) captures and sends the span to Sentry immediately. However, add_query_source() is called AFTER the span context manager exits in the SQLAlchemy integration. This means any attributes set by add_query_source() (like code.line.number, code.file.path, code.function.name) will be lost because the span has already been transmitted.

Line 486 contains print(span) which appears to be a debug statement accidentally left in. This will output noise to stdout during every test that uses the render_span_tree fixture, potentially cluttering test output and making actual test failures harder to identify.

In test_transactions, the span_streaming branch at line 162 only asserts SPANDATA.SERVER_PORT not in span["attributes"], while the non-streaming branch at lines 203-204 asserts both SERVER_ADDRESS and SERVER_PORT. This test coverage gap means the span_streaming mode might emit SERVER_ADDRESS when it shouldn't (for sqlite:///:memory: which has no host), and this bug would go undetected.

In test_long_sql_query_preserved when span_streaming=True, the code accesses spans[0] assuming it's the SQL query span. However, capture_items("span") captures all spans including the parent "custom parent" span. Unlike test_transactions which filters for sqlalchemy_spans using sentry.origin attribute, this test directly accesses spans[0]. The test may pass by accident due to span ordering, but the assertion is on the wrong span.