feat(span-first): Remove active from startSpan options

[buenaflor]

DESCRIBE YOUR PR

Tell us what you're changing and why. If your PR resolves an issue, please link it so it closes automatically.
Removes active from startSpan

IS YOUR CHANGE URGENT?

Help us prioritize incoming PRs by letting us know when the change needs to go live.

• Urgent deadline (GA date, etc.):
• Other deadline:
• None: Not urgent, can wait up to 1 week+

SLA

• Teamwork makes the dream work, so please add a reviewer to your PRs.
• Please give the docs team up to 1 week to review your PR unless you've added an urgent due date to it.
  Thanks in advance for your help!

PRE-MERGE CHECKLIST

Make sure you've checked the following before merging your changes:

• Checked Vercel preview for correctness, including links
• PR was reviewed and approved by any necessary SMEs (subject matter experts)
• PR was reviewed and approved by a member of the Sentry docs team

LEGAL BOILERPLATE

Look, I get it. The entity doing business as "Sentry" was incorporated in the State of Delaware in 2015 as Functional Software, Inc. and is gonna need some rights from me in order to utilize my contributions in this here PR. So here's the deal: I retain all rights, title and interest in and to my contributions, and by keeping this boilerplate intact I confirm that Sentry can use, modify, copy, and redistribute my contributions, under Sentry's choice of terms.

EXTRA RESOURCES

• Sentry Docs contributor guide

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Review	Updated (UTC)
develop-docs	Ready	Preview, Comment	Jan 14, 2026 10:25am

1 Skipped Deployment

Project	Deployment	Review	Updated (UTC)
sentry-docs	Ignored		Jan 14, 2026 10:25am

[buenaflor]

pls double check in case I misunderstood

[Lms24]

I think you're correct here in terms of how we discussed it. But I realized that this might not be what we want. See my comment below

[Lms24]

Before we merge this I would like to confirm that the replacement is sound.

With this change, we put more work on users:

• previously, they could mark one span as active: false, and all potential spans started while said span was running, would be attached to the active span (i.e. not the one marked)
• now, with the proposed change, every span that might be started while the span that should be inactive is running, must explicitly set another parent. This gets especially tricky if we're talking about auto instrumentation.

I would argue there are good reasons for still starting individual inactive spans without having to care about others.

Pseudocode example

// Assume: fetch calls are instrumented automatically, creating `http.client` spans

const myParentSpan = Sentry.startSpan({name: 'parent'});

fetch('/resource-1').then(...);
fetch('/resource-2').then(...);

myParentSpan.end()

If the fetch spans are not started as inactive, we end up with this hierarchy:

• parent
  • fetch resource-1
    • fetch resource-2

and there's little we can do about that, given fetch calls are auto instrumented.

While if auto instrumentation can start fetch spans with active: false, we get the "correct" hierarchy:

• parent
  • fetch resource-1
  • fetch resource-2

Fwiw, I think http.client spans are good examples for inactive spans, since there's rarely a reason to attach a child span to them (if ever?). We currently start http.client spans as inactive spans in JS.

[cleptric]

Android/Java has http.client child spans.