Conversation
Semver Impact of This PR🟡 Minor (new features) 📋 Changelog PreviewThis is how your changes will appear in the changelog. New Features ✨Anthropic
Pydantic Ai
Other
Bug Fixes 🐛
Documentation 📚
Internal Changes 🔧Anthropic
Docs
Openai Agents
Other
🤖 This preview updates automatically when you update the PR. |
Codecov Results 📊✅ 13 passed | Total: 13 | Pass Rate: 100% | Execution Time: 15.06s All tests are passing successfully. ❌ Patch coverage is 6.06%. Project has 14293 uncovered lines. Files with missing lines (1)
Generated by Codecov Action |
| segment = sentry_sdk.traces.start_span( | ||
| name=transaction_name, attributes=attributes | ||
| ) | ||
| span_ctx = segment or nullcontext() |
There was a problem hiding this comment.
Span streaming mode starts spans for HTTP requests not in http_methods_to_capture
In span streaming mode, when ty is 'http' and the method is NOT in http_methods_to_capture, a span is still created (line 237-238). In contrast, the legacy mode correctly skips transaction creation, leaving transaction = None and using nullcontext(). This behavioral difference means span streaming will generate spans for filtered-out HTTP methods (e.g., OPTIONS, HEAD) when users explicitly configured http_methods_to_capture to exclude them, causing unexpected tracing overhead and data noise.
Verification
Traced both code paths in _run_app: Legacy mode (lines 242-274) only creates a transaction when ty is http/websocket AND method is in http_methods_to_capture, otherwise transaction stays None. Span streaming mode (lines 217-240) always creates a span at line 237 regardless of whether the inner condition (lines 222-227) was met. Read full asgi.py file and traces.py to confirm StreamedSpan behavior.
Identified by Warden code-review, find-bugs · KTW-XF2
There was a problem hiding this comment.
Fix attempt detected (commit a4dbe50)
The span streaming mode still calls sentry_sdk.traces.start_span() unconditionally on line 237 regardless of whether the HTTP method is in http_methods_to_capture, meaning spans are still created for filtered HTTP methods despite the conditional logic checking the method filter.
The original issue appears unresolved. Please review and try again.
Evaluated by Warden
This PR makes the ASGI integration work both in legacy and span streaming mode. Some features and attributes will be missing in span streaming mode for now (see the Out of scope section below).
Migrating integrations
In order to support both legacy spans and span streaming, most integrations will follow the same patterns:
Transactions are gone
There are no transactions anymore. Top-level spans will also be started via the
start_spanAPI.Setting data on spans
If an integration sets data on a span (via
span.set_data,span.set_tagetc.), it should usespan.set_attributewhen span streaming is enabled.The attributes that we set need to be in Sentry conventions. This is deliberately not the case for most quick ports of integrations like this one and will follow in a future step.
Trace propagation
If an integration sits at a service boundary and is capable of propagating incoming trace information (like WSGI/ASGI or Celery), in span first mode we need to switch from the old style
with continue_trace(...) as transaction:to the new stylecontinue_trace()andnew_trace()(not context managers).start_spanargumentsYou can pass things like
op,origin,sourceto the oldstart_spanAPI. With the new API, this is no longer possible, and the individual properties need to be set as attributes directly.Out of scope
For now, the following is out of scope and will follow in the future: