feat(starlette): Support span streaming

[ericapisani]

Bring the Starlette integration to span-streaming parity with the FastAPI change that landed in #6118.

Under the trace_lifecycle: "stream" experiment the scope's transaction is None and the scope instead holds a StreamedSpan, so the existing middleware instrumentation (which called start_span(op=..., origin=...) + set_tag) and the profiler's current_scope.transaction.update_active_thread() hook in patch_request_response didn't function under streaming. This PR routes both through the streaming APIs when streaming is enabled while leaving the legacy transaction-based path untouched:

• _enable_span_for_middleware now uses a _start_middleware_span helper that calls sentry_sdk.traces.start_span with sentry.op, sentry.origin, and starlette.middleware_name attributes under streaming, and the existing sentry_sdk.start_span(op=..., origin=...) + set_tag otherwise.
• The profiler hook detects StreamedSpan (excluding NoOpStreamedSpan) and calls _segment._update_active_thread(); otherwise it takes the legacy current_scope.transaction.update_active_thread() branch.

Tests are parametrized across streaming and static modes for test_middleware_spans, test_middleware_spans_disabled, test_middleware_callback_spans, and test_span_origin. A new test_active_thread_id_span_streaming covers the segment's thread.id attribute under streaming. auto_enabling_integrations=False is set in streaming tests where auto-instrumented spans would otherwise leak into the captured span stream.

Refs PY-2362

[linear-code]

PY-2362 Migrate starlette to span first

[github-actions]

Codecov Results 📊

✅ 13 passed | Total: 13 | Pass Rate: 100% | Execution Time: 8.75s

All tests are passing successfully.

❌ Patch coverage is 9.09%. Project has 14790 uncovered lines.

Files with missing lines (1)

File	Patch %	Lines
starlette.py	5.63%	⚠️ 352 Missing

---

Generated by Codecov Action

[sentrivana]

Nice, left a few comments -- we'll need to migrate the event processors as well.

[sentrivana]

starlette.middleware_name is not in Sentry semantic conventions -- anything we set as an attribute on a streamed span needs to be there. So we either need to add it or not set it at all.

In this case, if I read the code right, it seems to be the same as the span name? In that case I'd omit the attribute. If we want to keep it, I'd propose a new attribute name in Sentry conventions that's not tied to Starlette specifically, so that we can use it across different frameworks and languages.

[ericapisani]

starlette.middleware_name is not in Sentry semantic conventions -- anything we set as an attribute on a streamed span needs to be there. So we either need to add it or not set it at all.

I had assumed the following from the span-first migration docs applied since starlette.middleware_name is being set as a tag in the legacy approach:

In span streaming mode, spans have no contexts, data, or tags. Everything is a span attribute. It's therefore necessary to migrate all existing span.set_data(), span.set_context(), and span.set_tag() to span.set_attribute()

Re:

In this case, if I read the code right, it seems to be the same as the span name?

Not in this case - middleware_name is set to the value of app.__class__.__name__ (just above the is_span_streaming_enabled check) whereas the name set on the span differs depending on if this is invoked in the patched receive or send callbacks a little further below (receive and send links) and ultimately makes the name a different value from middleware_name

[sentrivana]

In span streaming mode, spans have no contexts, data, or tags. Everything is a span attribute. It's therefore necessary to migrate all existing span.set_data(), span.set_context(), and span.set_tag() to span.set_attribute()

This is true, but it's from the migration guide, which is a user facing artifact -- it doesn't mention sentry conventions since that only applies to attributes set by the SDK.

This #5386 has more detailed info on the SDK-set attrs:

When translating old contexts, data, tags etc. to span attributes, follow Sentry conventions. If anything is unclear or there's an attribute missing, raise on Slack in #proj-span-first-sentry as product folks also need to be aligned on attribute changes.

---

Not in this case - middleware_name is set to the value of app.class.name (just above the is_span_streaming_enabled check) whereas the name set on the span differs depending on if this is invoked in the patched receive or send callbacks a little further below (receive and send links) and ultimately makes the name a different value from middleware_name

Gotcha. In that case adding a convention for middleware names would be the way to go.

[ericapisani]

When translating old contexts, data, tags etc. to span attributes, follow Sentry conventions. If anything is unclear or there's an attribute missing, raise on Slack in #proj-span-first-sentry as product folks also need to be aligned on attribute changes.

Ah, that's my oversight, I'll be more careful checking that list instead going forward!

And otherwise, sounds good, will add the missing things to the conventions 🚀

[sentrivana]

We're adding an event processor here. In legacy mode, it would enrich any transaction event with additional data. Since streamed spans are not events, it'll not apply, so anytime there's an event processor in an integration, we need to come up with an equivalent way to apply the data to streaming segments as well.

The gist is basically:

• Leave the event processor in place since it should continue working for other event types, like errors, as well, in the future.
• The span streaming version of this will basically be us setting equivalent attributes (which need to be in conventions) on the segment span.
• Event processors are normally run at the very end of the transaction lifecycle. Depending on what data they set, the span streaming equivalent might also need to be run towards the end of the segment's lifetime -- it depends on whether any of the data we set can be expected to be populated only later (like, for instance, the response status code).

Have a look at ASGI for prior art.

Ideally, this would've popped up in the tests. Looks like we're not really testing that the event processor applies the correct data, since the tests are passing even without it. That's not great. But we can also address that at a later point since it's out of scope of this PR.

[sentrivana]

We'll also need to port this event processor