Skip to content

Conversation

@sentrivana
Copy link
Contributor

@sentrivana sentrivana commented Jan 15, 2026

Introduce a new start_span() API with a simpler and more intuitive signature to eventually replace the original start_span() and start_transaction() APIs.

Additionally, introduce a new streaming mode (sentry_sdk.init(_experiments={"trace_lifecycle": "stream"})) that will send spans as they finish, rather than by transaction.

import sentry_sdk

sentry_sdk.init(
    _experiments={"trace_lifecycle": "stream"},
)

with sentry_sdk.traces.start_span(name="my_span"):
    ...

The new API MUST be used with the new streaming mode, and the old API MUST be used in the legacy non-streaming (static) mode.

Migration guide: getsentry/sentry-docs#16072

Notes

  • The diff is huge mostly because I've optimized for easy removal of legacy code in the next major, deliberately duplicating a lot. I'll of course split it up to reviewable PRs once ready.
    • Chose to go with a new file and a new span class so that we can just remove the old Span and drop the new StreamedSpan in tracing.py as a replacement.
  • The batcher for spans is a bit different from the logs and metrics batchers because it needs to batch by trace_id (we can't send spans from different traces in the same envelope).

Release Plan

  • There will be prereleases for internal testing.
  • We'll release the new API in a minor version as opt-in.
  • In the next major, we'll drop the legacy API.

Project

https://linear.app/getsentry/project/span-first-sdk-python-727da28dd037/overview

@github-actions
Copy link
Contributor

github-actions bot commented Jan 15, 2026

Semver Impact of This PR

None (no version bump detected)

📋 Changelog Preview

This is how your changes will appear in the changelog.
Entries from this PR are highlighted with a left border (blockquote style).


  • [do not merge] feat: Span streaming & new span API by sentrivana in #5317

🤖 This preview updates automatically when you update the PR.

sentrivana added a commit that referenced this pull request Feb 4, 2026
- add setters(/getters) or properties for `op`, `source`, `name`,
`origin`, `status`, feature flags, `span_id`
- also, rename `name` -> `_name` since it has a getter/setter now

In general regarding this getter/setter business vs. property-based
getting and setting: The idiomatic way would be to use properties (e.g.
`span.name = "name"`), but since we can't get around having _some_
getters/setters (e.g. `set_attribute`, `set_flag`, etc.), it's probably
better to go for consistency and have getters/setters everywhere, even
if it's not idiomatic. Otherwise users would have to remember if the
specific thing they want to set is a property or has a setter.

The above is about stuff people might want to set, so public API. For
internal stuff that no one should be setting by hand (e.g. `span_id`),
we can still go with properties where it makes sense.

Chipping away at #5317.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants