feat(core): Seal SentryTracerProvider spans against mutation after they end

[andreiborza]

What

Seal spans created by the SentryTracerProvider once they end. After SentrySpan.end() finishes its end-of-span processing, every mutator no-ops, gated on the spanIsTracerProviderSpan brand:

• setAttribute / setAttributes
• setStatus
• updateName
• updateStartTime
• addLink / addLinks
• addEvent

Spans created directly through core (e.g. the browser SDK) are never branded, so they stay mutable.

Why

OpenTelemetry SDK spans are immutable after end() (setters no-op). The SentryTracerProvider hands native SentrySpans to OTel instrumentations as OTel spans, so they must honor that contract. Some instrumentations write to a span after end() (e.g. Next.js sets a status on a render error); without sealing, those late writes overwrite the finalized values.

This matters most once segment-span capture is deferred (#21839): the transaction snapshot is then taken on a later tick, so any late post-end() write (status, attribute, name, start time, link, or event) would be serialized into it. Sealing the span on end() keeps the finalized values intact.

Notes

• The seal applies only to provider-branded spans. The brand is set exclusively by the OTel SentryTracer, never by the browser SDK, so browser spans (including web-vitals start-time adjustments via updateStartTime) are unaffected.
• Tests in sentrySpan.test.ts cover both directions: a branded span where all mutators no-op after end(), and a non-branded span that stays mutable.

Stacked on #21839 (deferred capture / orphan emission) and #21666 (which provides the spanIsTracerProviderSpan brand). Dormant until #21680 wires the provider; no provider-branded spans exist before then.

[github-actions]

size-limit report 📦

Path	Size	% Change	Change
@sentry/browser	27.59 kB	-	-
@sentry/browser - with treeshaking flags	26.03 kB	-	-
@sentry/browser (incl. Tracing)	46.24 kB	+0.46%	+209 B 🔺
@sentry/browser (incl. Tracing + Span Streaming)	48 kB	+0.47%	+222 B 🔺
@sentry/browser (incl. Tracing, Profiling)	51.01 kB	+0.41%	+205 B 🔺
@sentry/browser (incl. Tracing, Replay)	85.49 kB	+0.27%	+224 B 🔺
@sentry/browser (incl. Tracing, Replay) - with treeshaking flags	75.1 kB	+0.31%	+225 B 🔺
@sentry/browser (incl. Tracing, Replay with Canvas)	90.19 kB	+0.26%	+232 B 🔺
@sentry/browser (incl. Tracing, Replay, Feedback)	102.84 kB	+0.23%	+226 B 🔺
@sentry/browser (incl. Feedback)	44.76 kB	-	-
@sentry/browser (incl. sendFeedback)	32.38 kB	-	-
@sentry/browser (incl. FeedbackAsync)	37.51 kB	-	-
@sentry/browser (incl. Metrics)	28.67 kB	-	-
@sentry/browser (incl. Logs)	28.91 kB	-	-
@sentry/browser (incl. Metrics & Logs)	29.59 kB	-	-
@sentry/react	29.38 kB	-	-
@sentry/react (incl. Tracing)	48.51 kB	+0.35%	+169 B 🔺
@sentry/vue	33.03 kB	+0.64%	+207 B 🔺
@sentry/vue (incl. Tracing)	48.11 kB	+0.43%	+205 B 🔺
@sentry/svelte	27.61 kB	-	-
CDN Bundle	30 kB	-	-
CDN Bundle (incl. Tracing)	48.22 kB	+0.46%	+219 B 🔺
CDN Bundle (incl. Logs, Metrics)	31.57 kB	-	-
CDN Bundle (incl. Tracing, Logs, Metrics)	49.53 kB	+0.4%	+194 B 🔺
CDN Bundle (incl. Replay, Logs, Metrics)	70.77 kB	-	-
CDN Bundle (incl. Tracing, Replay)	85.68 kB	+0.24%	+200 B 🔺
CDN Bundle (incl. Tracing, Replay, Logs, Metrics)	86.97 kB	+0.24%	+204 B 🔺
CDN Bundle (incl. Tracing, Replay, Feedback)	91.5 kB	+0.22%	+200 B 🔺
CDN Bundle (incl. Tracing, Replay, Feedback, Logs, Metrics)	92.77 kB	+0.24%	+222 B 🔺
CDN Bundle - uncompressed	89.35 kB	-	-
CDN Bundle (incl. Tracing) - uncompressed	145.92 kB	+0.45%	+649 B 🔺
CDN Bundle (incl. Logs, Metrics) - uncompressed	94.05 kB	-	-
CDN Bundle (incl. Tracing, Logs, Metrics) - uncompressed	149.89 kB	+0.44%	+649 B 🔺
CDN Bundle (incl. Replay, Logs, Metrics) - uncompressed	218.59 kB	-	-
CDN Bundle (incl. Tracing, Replay) - uncompressed	264.93 kB	+0.25%	+649 B 🔺
CDN Bundle (incl. Tracing, Replay, Logs, Metrics) - uncompressed	268.89 kB	+0.25%	+649 B 🔺
CDN Bundle (incl. Tracing, Replay, Feedback) - uncompressed	278.63 kB	+0.24%	+651 B 🔺
CDN Bundle (incl. Tracing, Replay, Feedback, Logs, Metrics) - uncompressed	282.58 kB	+0.24%	+651 B 🔺
@sentry/nextjs (client)	50.95 kB	+0.43%	+218 B 🔺
@sentry/sveltekit (client)	46.65 kB	+0.49%	+226 B 🔺
@sentry/core/server	78.28 kB	+0.72%	+552 B 🔺
@sentry/core/browser	64.62 kB	+0.88%	+563 B 🔺
@sentry/node-core	62.7 kB	+0.53%	+328 B 🔺
@sentry/node	121.53 kB	+0.26%	+306 B 🔺
@sentry/node/import (ESM hook with diagnostics-channel injection)	69.95 kB	-	-
@sentry/node/light	50.7 kB	+0.47%	+233 B 🔺
@sentry/node - without tracing	73.05 kB	+0.5%	+358 B 🔺
@sentry/aws-serverless	83.86 kB	+0.35%	+290 B 🔺
@sentry/cloudflare (withSentry) - minified	181.52 kB	+0.5%	+900 B 🔺
@sentry/cloudflare (withSentry)	449.12 kB	+0.52%	+2.29 kB 🔺

View base workflow run

[Lms24]

dumb q but is there anything we could do to avoid having this logic hard-baked into SentrySpan? No super strong opinion, but maybe medium-strong: Ideally we can keep our SentrySpan as size-efficient as possible and rather special-case provider-emitted spans. wdyt? I might be missing something that makes this more complicated/infeasible, so feel free to disregard

[andreiborza]

@Lms24 as discussed, this adds a lot of extra code. The SentryTracerProvider doesn't instantiate spans itself, it calls core startSpan apis so there's not an easy way to instantiate spans that have this logic in them just for the tracer provider path.

This change is about 60 bytes gzipped, so I think the impact shouldn't be too bad. Also, spans should probably be finalized for core and browser as well, but that's something we can take a look at a later point.

[JPeer264]

[JPeer264]

(After looking at other functions the following is a bad idea, but I'll keep it here for food for thoughts)

q: This might be an issue for a future method when we forget to add this._frozen. Would it make sense to add an this._update() function where we update certain fields and protect that?

E.g. here we would update the startTime with this._update({ startTime: '' }), while the this._update is guarded with the this._frozen check.

[andreiborza]

I'd rather not add more code to the SentrySpan, see Lukas' original objection. I think this kind of issue of forgetting to add is easily caught by review bots nowadays.

Also, realistically, I don't think we'll expose much more api on this class.

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 8a1f780. Configure here.}

[andreiborza]

What

Seal spans created by the SentryTracerProvider once they end. After SentrySpan.end() finishes its end-of-span processing, every mutator no-ops, gated on the spanIsTracerProviderSpan brand:

• setAttribute / setAttributes
• setStatus
• updateName
• updateStartTime
• addLink / addLinks
• addEvent

Spans created directly through core (e.g. the browser SDK) are never branded, so they stay mutable.

Why

OpenTelemetry SDK spans are immutable after end() (setters no-op). The SentryTracerProvider hands native SentrySpans to OTel instrumentations as OTel spans, so they must honor that contract. Some instrumentations write to a span after end() (e.g. Next.js sets a status on a render error); without sealing, those late writes overwrite the finalized values.

This matters most once segment-span capture is deferred (#21839): the transaction snapshot is then taken on a later tick, so any late post-end() write (status, attribute, name, start time, link, or event) would be serialized into it. Sealing the span on end() keeps the finalized values intact.

Notes

• The seal applies only to provider-branded spans. The brand is set exclusively by the OTel SentryTracer, never by the browser SDK, so browser spans (including web-vitals start-time adjustments via updateStartTime) are unaffected.
• Tests in sentrySpan.test.ts cover both directions: a branded span where all mutators no-op after end(), and a non-branded span that stays mutable.

Stacked on #21839 (deferred capture / orphan emission) and #21666 (which provides the spanIsTracerProviderSpan brand). Dormant until #21680 wires the provider; no provider-branded spans exist before then.

[github-actions]

size-limit report 📦

Path	Size	% Change	Change
@sentry/browser	27.59 kB	-	-
@sentry/browser - with treeshaking flags	26.03 kB	-	-
@sentry/browser (incl. Tracing)	46.24 kB	+0.46%	+209 B 🔺
@sentry/browser (incl. Tracing + Span Streaming)	48 kB	+0.47%	+222 B 🔺
@sentry/browser (incl. Tracing, Profiling)	51.01 kB	+0.41%	+205 B 🔺
@sentry/browser (incl. Tracing, Replay)	85.49 kB	+0.27%	+224 B 🔺
@sentry/browser (incl. Tracing, Replay) - with treeshaking flags	75.1 kB	+0.31%	+225 B 🔺
@sentry/browser (incl. Tracing, Replay with Canvas)	90.19 kB	+0.26%	+232 B 🔺
@sentry/browser (incl. Tracing, Replay, Feedback)	102.84 kB	+0.23%	+226 B 🔺
@sentry/browser (incl. Feedback)	44.76 kB	-	-
@sentry/browser (incl. sendFeedback)	32.38 kB	-	-
@sentry/browser (incl. FeedbackAsync)	37.51 kB	-	-
@sentry/browser (incl. Metrics)	28.67 kB	-	-
@sentry/browser (incl. Logs)	28.91 kB	-	-
@sentry/browser (incl. Metrics & Logs)	29.59 kB	-	-
@sentry/react	29.38 kB	-	-
@sentry/react (incl. Tracing)	48.51 kB	+0.35%	+169 B 🔺
@sentry/vue	33.03 kB	+0.64%	+207 B 🔺
@sentry/vue (incl. Tracing)	48.11 kB	+0.43%	+205 B 🔺
@sentry/svelte	27.61 kB	-	-
CDN Bundle	30 kB	-	-
CDN Bundle (incl. Tracing)	48.22 kB	+0.46%	+219 B 🔺
CDN Bundle (incl. Logs, Metrics)	31.57 kB	-	-
CDN Bundle (incl. Tracing, Logs, Metrics)	49.53 kB	+0.4%	+194 B 🔺
CDN Bundle (incl. Replay, Logs, Metrics)	70.77 kB	-	-
CDN Bundle (incl. Tracing, Replay)	85.68 kB	+0.24%	+200 B 🔺
CDN Bundle (incl. Tracing, Replay, Logs, Metrics)	86.97 kB	+0.24%	+204 B 🔺
CDN Bundle (incl. Tracing, Replay, Feedback)	91.5 kB	+0.22%	+200 B 🔺
CDN Bundle (incl. Tracing, Replay, Feedback, Logs, Metrics)	92.77 kB	+0.24%	+222 B 🔺
CDN Bundle - uncompressed	89.35 kB	-	-
CDN Bundle (incl. Tracing) - uncompressed	145.92 kB	+0.45%	+649 B 🔺
CDN Bundle (incl. Logs, Metrics) - uncompressed	94.05 kB	-	-
CDN Bundle (incl. Tracing, Logs, Metrics) - uncompressed	149.89 kB	+0.44%	+649 B 🔺
CDN Bundle (incl. Replay, Logs, Metrics) - uncompressed	218.59 kB	-	-
CDN Bundle (incl. Tracing, Replay) - uncompressed	264.93 kB	+0.25%	+649 B 🔺
CDN Bundle (incl. Tracing, Replay, Logs, Metrics) - uncompressed	268.89 kB	+0.25%	+649 B 🔺
CDN Bundle (incl. Tracing, Replay, Feedback) - uncompressed	278.63 kB	+0.24%	+651 B 🔺
CDN Bundle (incl. Tracing, Replay, Feedback, Logs, Metrics) - uncompressed	282.58 kB	+0.24%	+651 B 🔺
@sentry/nextjs (client)	50.95 kB	+0.43%	+218 B 🔺
@sentry/sveltekit (client)	46.65 kB	+0.49%	+226 B 🔺
@sentry/core/server	78.28 kB	+0.72%	+552 B 🔺
@sentry/core/browser	64.62 kB	+0.88%	+563 B 🔺
@sentry/node-core	62.7 kB	+0.53%	+328 B 🔺
@sentry/node	121.53 kB	+0.26%	+306 B 🔺
@sentry/node/import (ESM hook with diagnostics-channel injection)	69.95 kB	-	-
@sentry/node/light	50.7 kB	+0.47%	+233 B 🔺
@sentry/node - without tracing	73.05 kB	+0.5%	+358 B 🔺
@sentry/aws-serverless	83.86 kB	+0.35%	+290 B 🔺
@sentry/cloudflare (withSentry) - minified	181.52 kB	+0.5%	+900 B 🔺
@sentry/cloudflare (withSentry)	449.12 kB	+0.52%	+2.29 kB 🔺

View base workflow run

[Lms24]

dumb q but is there anything we could do to avoid having this logic hard-baked into SentrySpan? No super strong opinion, but maybe medium-strong: Ideally we can keep our SentrySpan as size-efficient as possible and rather special-case provider-emitted spans. wdyt? I might be missing something that makes this more complicated/infeasible, so feel free to disregard

[andreiborza]

@Lms24 as discussed, this adds a lot of extra code. The SentryTracerProvider doesn't instantiate spans itself, it calls core startSpan apis so there's not an easy way to instantiate spans that have this logic in them just for the tracer provider path.

This change is about 60 bytes gzipped, so I think the impact shouldn't be too bad. Also, spans should probably be finalized for core and browser as well, but that's something we can take a look at a later point.

[JPeer264]

[JPeer264]

(After looking at other functions the following is a bad idea, but I'll keep it here for food for thoughts)

q: This might be an issue for a future method when we forget to add this._frozen. Would it make sense to add an this._update() function where we update certain fields and protect that?

E.g. here we would update the startTime with this._update({ startTime: '' }), while the this._update is guarded with the this._frozen check.

[andreiborza]

I'd rather not add more code to the SentrySpan, see Lukas' original objection. I think this kind of issue of forgetting to add is easily caught by review bots nowadays.

Also, realistically, I don't think we'll expose much more api on this class.

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 8a1f780. Configure here.}

[andreiborza]

What

Seal spans created by the SentryTracerProvider once they end. After SentrySpan.end() finishes its end-of-span processing, every mutator no-ops, gated on the spanIsTracerProviderSpan brand:

• setAttribute / setAttributes
• setStatus
• updateName
• updateStartTime
• addLink / addLinks
• addEvent

Spans created directly through core (e.g. the browser SDK) are never branded, so they stay mutable.

Why

OpenTelemetry SDK spans are immutable after end() (setters no-op). The SentryTracerProvider hands native SentrySpans to OTel instrumentations as OTel spans, so they must honor that contract. Some instrumentations write to a span after end() (e.g. Next.js sets a status on a render error); without sealing, those late writes overwrite the finalized values.

This matters most once segment-span capture is deferred (#21839): the transaction snapshot is then taken on a later tick, so any late post-end() write (status, attribute, name, start time, link, or event) would be serialized into it. Sealing the span on end() keeps the finalized values intact.

Notes

• The seal applies only to provider-branded spans. The brand is set exclusively by the OTel SentryTracer, never by the browser SDK, so browser spans (including web-vitals start-time adjustments via updateStartTime) are unaffected.
• Tests in sentrySpan.test.ts cover both directions: a branded span where all mutators no-op after end(), and a non-branded span that stays mutable.

Stacked on #21839 (deferred capture / orphan emission) and #21666 (which provides the spanIsTracerProviderSpan brand). Dormant until #21680 wires the provider; no provider-branded spans exist before then.

[github-actions]

size-limit report 📦

Path	Size	% Change	Change
@sentry/browser	27.59 kB	-	-
@sentry/browser - with treeshaking flags	26.03 kB	-	-
@sentry/browser (incl. Tracing)	46.24 kB	+0.46%	+209 B 🔺
@sentry/browser (incl. Tracing + Span Streaming)	48 kB	+0.47%	+222 B 🔺
@sentry/browser (incl. Tracing, Profiling)	51.01 kB	+0.41%	+205 B 🔺
@sentry/browser (incl. Tracing, Replay)	85.49 kB	+0.27%	+224 B 🔺
@sentry/browser (incl. Tracing, Replay) - with treeshaking flags	75.1 kB	+0.31%	+225 B 🔺
@sentry/browser (incl. Tracing, Replay with Canvas)	90.19 kB	+0.26%	+232 B 🔺
@sentry/browser (incl. Tracing, Replay, Feedback)	102.84 kB	+0.23%	+226 B 🔺
@sentry/browser (incl. Feedback)	44.76 kB	-	-
@sentry/browser (incl. sendFeedback)	32.38 kB	-	-
@sentry/browser (incl. FeedbackAsync)	37.51 kB	-	-
@sentry/browser (incl. Metrics)	28.67 kB	-	-
@sentry/browser (incl. Logs)	28.91 kB	-	-
@sentry/browser (incl. Metrics & Logs)	29.59 kB	-	-
@sentry/react	29.38 kB	-	-
@sentry/react (incl. Tracing)	48.51 kB	+0.35%	+169 B 🔺
@sentry/vue	33.03 kB	+0.64%	+207 B 🔺
@sentry/vue (incl. Tracing)	48.11 kB	+0.43%	+205 B 🔺
@sentry/svelte	27.61 kB	-	-
CDN Bundle	30 kB	-	-
CDN Bundle (incl. Tracing)	48.22 kB	+0.46%	+219 B 🔺
CDN Bundle (incl. Logs, Metrics)	31.57 kB	-	-
CDN Bundle (incl. Tracing, Logs, Metrics)	49.53 kB	+0.4%	+194 B 🔺
CDN Bundle (incl. Replay, Logs, Metrics)	70.77 kB	-	-
CDN Bundle (incl. Tracing, Replay)	85.68 kB	+0.24%	+200 B 🔺
CDN Bundle (incl. Tracing, Replay, Logs, Metrics)	86.97 kB	+0.24%	+204 B 🔺
CDN Bundle (incl. Tracing, Replay, Feedback)	91.5 kB	+0.22%	+200 B 🔺
CDN Bundle (incl. Tracing, Replay, Feedback, Logs, Metrics)	92.77 kB	+0.24%	+222 B 🔺
CDN Bundle - uncompressed	89.35 kB	-	-
CDN Bundle (incl. Tracing) - uncompressed	145.92 kB	+0.45%	+649 B 🔺
CDN Bundle (incl. Logs, Metrics) - uncompressed	94.05 kB	-	-
CDN Bundle (incl. Tracing, Logs, Metrics) - uncompressed	149.89 kB	+0.44%	+649 B 🔺
CDN Bundle (incl. Replay, Logs, Metrics) - uncompressed	218.59 kB	-	-
CDN Bundle (incl. Tracing, Replay) - uncompressed	264.93 kB	+0.25%	+649 B 🔺
CDN Bundle (incl. Tracing, Replay, Logs, Metrics) - uncompressed	268.89 kB	+0.25%	+649 B 🔺
CDN Bundle (incl. Tracing, Replay, Feedback) - uncompressed	278.63 kB	+0.24%	+651 B 🔺
CDN Bundle (incl. Tracing, Replay, Feedback, Logs, Metrics) - uncompressed	282.58 kB	+0.24%	+651 B 🔺
@sentry/nextjs (client)	50.95 kB	+0.43%	+218 B 🔺
@sentry/sveltekit (client)	46.65 kB	+0.49%	+226 B 🔺
@sentry/core/server	78.28 kB	+0.72%	+552 B 🔺
@sentry/core/browser	64.62 kB	+0.88%	+563 B 🔺
@sentry/node-core	62.7 kB	+0.53%	+328 B 🔺
@sentry/node	121.53 kB	+0.26%	+306 B 🔺
@sentry/node/import (ESM hook with diagnostics-channel injection)	69.95 kB	-	-
@sentry/node/light	50.7 kB	+0.47%	+233 B 🔺
@sentry/node - without tracing	73.05 kB	+0.5%	+358 B 🔺
@sentry/aws-serverless	83.86 kB	+0.35%	+290 B 🔺
@sentry/cloudflare (withSentry) - minified	181.52 kB	+0.5%	+900 B 🔺
@sentry/cloudflare (withSentry)	449.12 kB	+0.52%	+2.29 kB 🔺

View base workflow run

[Lms24]

dumb q but is there anything we could do to avoid having this logic hard-baked into SentrySpan? No super strong opinion, but maybe medium-strong: Ideally we can keep our SentrySpan as size-efficient as possible and rather special-case provider-emitted spans. wdyt? I might be missing something that makes this more complicated/infeasible, so feel free to disregard

[andreiborza]

@Lms24 as discussed, this adds a lot of extra code. The SentryTracerProvider doesn't instantiate spans itself, it calls core startSpan apis so there's not an easy way to instantiate spans that have this logic in them just for the tracer provider path.

This change is about 60 bytes gzipped, so I think the impact shouldn't be too bad. Also, spans should probably be finalized for core and browser as well, but that's something we can take a look at a later point.

[JPeer264]

[JPeer264]

(After looking at other functions the following is a bad idea, but I'll keep it here for food for thoughts)

q: This might be an issue for a future method when we forget to add this._frozen. Would it make sense to add an this._update() function where we update certain fields and protect that?

E.g. here we would update the startTime with this._update({ startTime: '' }), while the this._update is guarded with the this._frozen check.

[andreiborza]

I'd rather not add more code to the SentrySpan, see Lukas' original objection. I think this kind of issue of forgetting to add is easily caught by review bots nowadays.

Also, realistically, I don't think we'll expose much more api on this class.

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 8a1f780. Configure here.}

[andreiborza]

What

Seal spans created by the SentryTracerProvider once they end. After SentrySpan.end() finishes its end-of-span processing, every mutator no-ops, gated on the spanIsTracerProviderSpan brand:

• setAttribute / setAttributes
• setStatus
• updateName
• updateStartTime
• addLink / addLinks
• addEvent

Spans created directly through core (e.g. the browser SDK) are never branded, so they stay mutable.

Why

OpenTelemetry SDK spans are immutable after end() (setters no-op). The SentryTracerProvider hands native SentrySpans to OTel instrumentations as OTel spans, so they must honor that contract. Some instrumentations write to a span after end() (e.g. Next.js sets a status on a render error); without sealing, those late writes overwrite the finalized values.

This matters most once segment-span capture is deferred (#21839): the transaction snapshot is then taken on a later tick, so any late post-end() write (status, attribute, name, start time, link, or event) would be serialized into it. Sealing the span on end() keeps the finalized values intact.

Notes

• The seal applies only to provider-branded spans. The brand is set exclusively by the OTel SentryTracer, never by the browser SDK, so browser spans (including web-vitals start-time adjustments via updateStartTime) are unaffected.
• Tests in sentrySpan.test.ts cover both directions: a branded span where all mutators no-op after end(), and a non-branded span that stays mutable.

Stacked on #21839 (deferred capture / orphan emission) and #21666 (which provides the spanIsTracerProviderSpan brand). Dormant until #21680 wires the provider; no provider-branded spans exist before then.

[github-actions]

size-limit report 📦

Path	Size	% Change	Change
@sentry/browser	27.59 kB	-	-
@sentry/browser - with treeshaking flags	26.03 kB	-	-
@sentry/browser (incl. Tracing)	46.24 kB	+0.46%	+209 B 🔺
@sentry/browser (incl. Tracing + Span Streaming)	48 kB	+0.47%	+222 B 🔺
@sentry/browser (incl. Tracing, Profiling)	51.01 kB	+0.41%	+205 B 🔺
@sentry/browser (incl. Tracing, Replay)	85.49 kB	+0.27%	+224 B 🔺
@sentry/browser (incl. Tracing, Replay) - with treeshaking flags	75.1 kB	+0.31%	+225 B 🔺
@sentry/browser (incl. Tracing, Replay with Canvas)	90.19 kB	+0.26%	+232 B 🔺
@sentry/browser (incl. Tracing, Replay, Feedback)	102.84 kB	+0.23%	+226 B 🔺
@sentry/browser (incl. Feedback)	44.76 kB	-	-
@sentry/browser (incl. sendFeedback)	32.38 kB	-	-
@sentry/browser (incl. FeedbackAsync)	37.51 kB	-	-
@sentry/browser (incl. Metrics)	28.67 kB	-	-
@sentry/browser (incl. Logs)	28.91 kB	-	-
@sentry/browser (incl. Metrics & Logs)	29.59 kB	-	-
@sentry/react	29.38 kB	-	-
@sentry/react (incl. Tracing)	48.51 kB	+0.35%	+169 B 🔺
@sentry/vue	33.03 kB	+0.64%	+207 B 🔺
@sentry/vue (incl. Tracing)	48.11 kB	+0.43%	+205 B 🔺
@sentry/svelte	27.61 kB	-	-
CDN Bundle	30 kB	-	-
CDN Bundle (incl. Tracing)	48.22 kB	+0.46%	+219 B 🔺
CDN Bundle (incl. Logs, Metrics)	31.57 kB	-	-
CDN Bundle (incl. Tracing, Logs, Metrics)	49.53 kB	+0.4%	+194 B 🔺
CDN Bundle (incl. Replay, Logs, Metrics)	70.77 kB	-	-
CDN Bundle (incl. Tracing, Replay)	85.68 kB	+0.24%	+200 B 🔺
CDN Bundle (incl. Tracing, Replay, Logs, Metrics)	86.97 kB	+0.24%	+204 B 🔺
CDN Bundle (incl. Tracing, Replay, Feedback)	91.5 kB	+0.22%	+200 B 🔺
CDN Bundle (incl. Tracing, Replay, Feedback, Logs, Metrics)	92.77 kB	+0.24%	+222 B 🔺
CDN Bundle - uncompressed	89.35 kB	-	-
CDN Bundle (incl. Tracing) - uncompressed	145.92 kB	+0.45%	+649 B 🔺
CDN Bundle (incl. Logs, Metrics) - uncompressed	94.05 kB	-	-
CDN Bundle (incl. Tracing, Logs, Metrics) - uncompressed	149.89 kB	+0.44%	+649 B 🔺
CDN Bundle (incl. Replay, Logs, Metrics) - uncompressed	218.59 kB	-	-
CDN Bundle (incl. Tracing, Replay) - uncompressed	264.93 kB	+0.25%	+649 B 🔺
CDN Bundle (incl. Tracing, Replay, Logs, Metrics) - uncompressed	268.89 kB	+0.25%	+649 B 🔺
CDN Bundle (incl. Tracing, Replay, Feedback) - uncompressed	278.63 kB	+0.24%	+651 B 🔺
CDN Bundle (incl. Tracing, Replay, Feedback, Logs, Metrics) - uncompressed	282.58 kB	+0.24%	+651 B 🔺
@sentry/nextjs (client)	50.95 kB	+0.43%	+218 B 🔺
@sentry/sveltekit (client)	46.65 kB	+0.49%	+226 B 🔺
@sentry/core/server	78.28 kB	+0.72%	+552 B 🔺
@sentry/core/browser	64.62 kB	+0.88%	+563 B 🔺
@sentry/node-core	62.7 kB	+0.53%	+328 B 🔺
@sentry/node	121.53 kB	+0.26%	+306 B 🔺
@sentry/node/import (ESM hook with diagnostics-channel injection)	69.95 kB	-	-
@sentry/node/light	50.7 kB	+0.47%	+233 B 🔺
@sentry/node - without tracing	73.05 kB	+0.5%	+358 B 🔺
@sentry/aws-serverless	83.86 kB	+0.35%	+290 B 🔺
@sentry/cloudflare (withSentry) - minified	181.52 kB	+0.5%	+900 B 🔺
@sentry/cloudflare (withSentry)	449.12 kB	+0.52%	+2.29 kB 🔺

View base workflow run

[Lms24]

dumb q but is there anything we could do to avoid having this logic hard-baked into SentrySpan? No super strong opinion, but maybe medium-strong: Ideally we can keep our SentrySpan as size-efficient as possible and rather special-case provider-emitted spans. wdyt? I might be missing something that makes this more complicated/infeasible, so feel free to disregard

[andreiborza]

@Lms24 as discussed, this adds a lot of extra code. The SentryTracerProvider doesn't instantiate spans itself, it calls core startSpan apis so there's not an easy way to instantiate spans that have this logic in them just for the tracer provider path.

This change is about 60 bytes gzipped, so I think the impact shouldn't be too bad. Also, spans should probably be finalized for core and browser as well, but that's something we can take a look at a later point.

[JPeer264]

[JPeer264]

(After looking at other functions the following is a bad idea, but I'll keep it here for food for thoughts)

q: This might be an issue for a future method when we forget to add this._frozen. Would it make sense to add an this._update() function where we update certain fields and protect that?

E.g. here we would update the startTime with this._update({ startTime: '' }), while the this._update is guarded with the this._frozen check.

[andreiborza]

I'd rather not add more code to the SentrySpan, see Lukas' original objection. I think this kind of issue of forgetting to add is easily caught by review bots nowadays.

Also, realistically, I don't think we'll expose much more api on this class.

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 8a1f780. Configure here.}

[andreiborza]

What

Seal spans created by the SentryTracerProvider once they end. After SentrySpan.end() finishes its end-of-span processing, every mutator no-ops, gated on the spanIsTracerProviderSpan brand:

• setAttribute / setAttributes
• setStatus
• updateName
• updateStartTime
• addLink / addLinks
• addEvent

Spans created directly through core (e.g. the browser SDK) are never branded, so they stay mutable.

Why

OpenTelemetry SDK spans are immutable after end() (setters no-op). The SentryTracerProvider hands native SentrySpans to OTel instrumentations as OTel spans, so they must honor that contract. Some instrumentations write to a span after end() (e.g. Next.js sets a status on a render error); without sealing, those late writes overwrite the finalized values.

This matters most once segment-span capture is deferred (#21839): the transaction snapshot is then taken on a later tick, so any late post-end() write (status, attribute, name, start time, link, or event) would be serialized into it. Sealing the span on end() keeps the finalized values intact.

Notes

• The seal applies only to provider-branded spans. The brand is set exclusively by the OTel SentryTracer, never by the browser SDK, so browser spans (including web-vitals start-time adjustments via updateStartTime) are unaffected.
• Tests in sentrySpan.test.ts cover both directions: a branded span where all mutators no-op after end(), and a non-branded span that stays mutable.

Stacked on #21839 (deferred capture / orphan emission) and #21666 (which provides the spanIsTracerProviderSpan brand). Dormant until #21680 wires the provider; no provider-branded spans exist before then.

[github-actions]

size-limit report 📦

Path	Size	% Change	Change
@sentry/browser	27.59 kB	-	-
@sentry/browser - with treeshaking flags	26.03 kB	-	-
@sentry/browser (incl. Tracing)	46.24 kB	+0.46%	+209 B 🔺
@sentry/browser (incl. Tracing + Span Streaming)	48 kB	+0.47%	+222 B 🔺
@sentry/browser (incl. Tracing, Profiling)	51.01 kB	+0.41%	+205 B 🔺
@sentry/browser (incl. Tracing, Replay)	85.49 kB	+0.27%	+224 B 🔺
@sentry/browser (incl. Tracing, Replay) - with treeshaking flags	75.1 kB	+0.31%	+225 B 🔺
@sentry/browser (incl. Tracing, Replay with Canvas)	90.19 kB	+0.26%	+232 B 🔺
@sentry/browser (incl. Tracing, Replay, Feedback)	102.84 kB	+0.23%	+226 B 🔺
@sentry/browser (incl. Feedback)	44.76 kB	-	-
@sentry/browser (incl. sendFeedback)	32.38 kB	-	-
@sentry/browser (incl. FeedbackAsync)	37.51 kB	-	-
@sentry/browser (incl. Metrics)	28.67 kB	-	-
@sentry/browser (incl. Logs)	28.91 kB	-	-
@sentry/browser (incl. Metrics & Logs)	29.59 kB	-	-
@sentry/react	29.38 kB	-	-
@sentry/react (incl. Tracing)	48.51 kB	+0.35%	+169 B 🔺
@sentry/vue	33.03 kB	+0.64%	+207 B 🔺
@sentry/vue (incl. Tracing)	48.11 kB	+0.43%	+205 B 🔺
@sentry/svelte	27.61 kB	-	-
CDN Bundle	30 kB	-	-
CDN Bundle (incl. Tracing)	48.22 kB	+0.46%	+219 B 🔺
CDN Bundle (incl. Logs, Metrics)	31.57 kB	-	-
CDN Bundle (incl. Tracing, Logs, Metrics)	49.53 kB	+0.4%	+194 B 🔺
CDN Bundle (incl. Replay, Logs, Metrics)	70.77 kB	-	-
CDN Bundle (incl. Tracing, Replay)	85.68 kB	+0.24%	+200 B 🔺
CDN Bundle (incl. Tracing, Replay, Logs, Metrics)	86.97 kB	+0.24%	+204 B 🔺
CDN Bundle (incl. Tracing, Replay, Feedback)	91.5 kB	+0.22%	+200 B 🔺
CDN Bundle (incl. Tracing, Replay, Feedback, Logs, Metrics)	92.77 kB	+0.24%	+222 B 🔺
CDN Bundle - uncompressed	89.35 kB	-	-
CDN Bundle (incl. Tracing) - uncompressed	145.92 kB	+0.45%	+649 B 🔺
CDN Bundle (incl. Logs, Metrics) - uncompressed	94.05 kB	-	-
CDN Bundle (incl. Tracing, Logs, Metrics) - uncompressed	149.89 kB	+0.44%	+649 B 🔺
CDN Bundle (incl. Replay, Logs, Metrics) - uncompressed	218.59 kB	-	-
CDN Bundle (incl. Tracing, Replay) - uncompressed	264.93 kB	+0.25%	+649 B 🔺
CDN Bundle (incl. Tracing, Replay, Logs, Metrics) - uncompressed	268.89 kB	+0.25%	+649 B 🔺
CDN Bundle (incl. Tracing, Replay, Feedback) - uncompressed	278.63 kB	+0.24%	+651 B 🔺
CDN Bundle (incl. Tracing, Replay, Feedback, Logs, Metrics) - uncompressed	282.58 kB	+0.24%	+651 B 🔺
@sentry/nextjs (client)	50.95 kB	+0.43%	+218 B 🔺
@sentry/sveltekit (client)	46.65 kB	+0.49%	+226 B 🔺
@sentry/core/server	78.28 kB	+0.72%	+552 B 🔺
@sentry/core/browser	64.62 kB	+0.88%	+563 B 🔺
@sentry/node-core	62.7 kB	+0.53%	+328 B 🔺
@sentry/node	121.53 kB	+0.26%	+306 B 🔺
@sentry/node/import (ESM hook with diagnostics-channel injection)	69.95 kB	-	-
@sentry/node/light	50.7 kB	+0.47%	+233 B 🔺
@sentry/node - without tracing	73.05 kB	+0.5%	+358 B 🔺
@sentry/aws-serverless	83.86 kB	+0.35%	+290 B 🔺
@sentry/cloudflare (withSentry) - minified	181.52 kB	+0.5%	+900 B 🔺
@sentry/cloudflare (withSentry)	449.12 kB	+0.52%	+2.29 kB 🔺

View base workflow run

[Lms24]

dumb q but is there anything we could do to avoid having this logic hard-baked into SentrySpan? No super strong opinion, but maybe medium-strong: Ideally we can keep our SentrySpan as size-efficient as possible and rather special-case provider-emitted spans. wdyt? I might be missing something that makes this more complicated/infeasible, so feel free to disregard

[andreiborza]

@Lms24 as discussed, this adds a lot of extra code. The SentryTracerProvider doesn't instantiate spans itself, it calls core startSpan apis so there's not an easy way to instantiate spans that have this logic in them just for the tracer provider path.

This change is about 60 bytes gzipped, so I think the impact shouldn't be too bad. Also, spans should probably be finalized for core and browser as well, but that's something we can take a look at a later point.

[JPeer264]

[JPeer264]

(After looking at other functions the following is a bad idea, but I'll keep it here for food for thoughts)

q: This might be an issue for a future method when we forget to add this._frozen. Would it make sense to add an this._update() function where we update certain fields and protect that?

E.g. here we would update the startTime with this._update({ startTime: '' }), while the this._update is guarded with the this._frozen check.

[andreiborza]

I'd rather not add more code to the SentrySpan, see Lukas' original objection. I think this kind of issue of forgetting to add is easily caught by review bots nowadays.

Also, realistically, I don't think we'll expose much more api on this class.

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 8a1f780. Configure here.}

[andreiborza]

What

Seal spans created by the SentryTracerProvider once they end. After SentrySpan.end() finishes its end-of-span processing, every mutator no-ops, gated on the spanIsTracerProviderSpan brand:

• setAttribute / setAttributes
• setStatus
• updateName
• updateStartTime
• addLink / addLinks
• addEvent

Spans created directly through core (e.g. the browser SDK) are never branded, so they stay mutable.

Why

OpenTelemetry SDK spans are immutable after end() (setters no-op). The SentryTracerProvider hands native SentrySpans to OTel instrumentations as OTel spans, so they must honor that contract. Some instrumentations write to a span after end() (e.g. Next.js sets a status on a render error); without sealing, those late writes overwrite the finalized values.

This matters most once segment-span capture is deferred (#21839): the transaction snapshot is then taken on a later tick, so any late post-end() write (status, attribute, name, start time, link, or event) would be serialized into it. Sealing the span on end() keeps the finalized values intact.

Notes

• The seal applies only to provider-branded spans. The brand is set exclusively by the OTel SentryTracer, never by the browser SDK, so browser spans (including web-vitals start-time adjustments via updateStartTime) are unaffected.
• Tests in sentrySpan.test.ts cover both directions: a branded span where all mutators no-op after end(), and a non-branded span that stays mutable.

Stacked on #21839 (deferred capture / orphan emission) and #21666 (which provides the spanIsTracerProviderSpan brand). Dormant until #21680 wires the provider; no provider-branded spans exist before then.

[github-actions]

size-limit report 📦

Path	Size	% Change	Change
@sentry/browser	27.59 kB	-	-
@sentry/browser - with treeshaking flags	26.03 kB	-	-
@sentry/browser (incl. Tracing)	46.24 kB	+0.46%	+209 B 🔺
@sentry/browser (incl. Tracing + Span Streaming)	48 kB	+0.47%	+222 B 🔺
@sentry/browser (incl. Tracing, Profiling)	51.01 kB	+0.41%	+205 B 🔺
@sentry/browser (incl. Tracing, Replay)	85.49 kB	+0.27%	+224 B 🔺
@sentry/browser (incl. Tracing, Replay) - with treeshaking flags	75.1 kB	+0.31%	+225 B 🔺
@sentry/browser (incl. Tracing, Replay with Canvas)	90.19 kB	+0.26%	+232 B 🔺
@sentry/browser (incl. Tracing, Replay, Feedback)	102.84 kB	+0.23%	+226 B 🔺
@sentry/browser (incl. Feedback)	44.76 kB	-	-
@sentry/browser (incl. sendFeedback)	32.38 kB	-	-
@sentry/browser (incl. FeedbackAsync)	37.51 kB	-	-
@sentry/browser (incl. Metrics)	28.67 kB	-	-
@sentry/browser (incl. Logs)	28.91 kB	-	-
@sentry/browser (incl. Metrics & Logs)	29.59 kB	-	-
@sentry/react	29.38 kB	-	-
@sentry/react (incl. Tracing)	48.51 kB	+0.35%	+169 B 🔺
@sentry/vue	33.03 kB	+0.64%	+207 B 🔺
@sentry/vue (incl. Tracing)	48.11 kB	+0.43%	+205 B 🔺
@sentry/svelte	27.61 kB	-	-
CDN Bundle	30 kB	-	-
CDN Bundle (incl. Tracing)	48.22 kB	+0.46%	+219 B 🔺
CDN Bundle (incl. Logs, Metrics)	31.57 kB	-	-
CDN Bundle (incl. Tracing, Logs, Metrics)	49.53 kB	+0.4%	+194 B 🔺
CDN Bundle (incl. Replay, Logs, Metrics)	70.77 kB	-	-
CDN Bundle (incl. Tracing, Replay)	85.68 kB	+0.24%	+200 B 🔺
CDN Bundle (incl. Tracing, Replay, Logs, Metrics)	86.97 kB	+0.24%	+204 B 🔺
CDN Bundle (incl. Tracing, Replay, Feedback)	91.5 kB	+0.22%	+200 B 🔺
CDN Bundle (incl. Tracing, Replay, Feedback, Logs, Metrics)	92.77 kB	+0.24%	+222 B 🔺
CDN Bundle - uncompressed	89.35 kB	-	-
CDN Bundle (incl. Tracing) - uncompressed	145.92 kB	+0.45%	+649 B 🔺
CDN Bundle (incl. Logs, Metrics) - uncompressed	94.05 kB	-	-
CDN Bundle (incl. Tracing, Logs, Metrics) - uncompressed	149.89 kB	+0.44%	+649 B 🔺
CDN Bundle (incl. Replay, Logs, Metrics) - uncompressed	218.59 kB	-	-
CDN Bundle (incl. Tracing, Replay) - uncompressed	264.93 kB	+0.25%	+649 B 🔺
CDN Bundle (incl. Tracing, Replay, Logs, Metrics) - uncompressed	268.89 kB	+0.25%	+649 B 🔺
CDN Bundle (incl. Tracing, Replay, Feedback) - uncompressed	278.63 kB	+0.24%	+651 B 🔺
CDN Bundle (incl. Tracing, Replay, Feedback, Logs, Metrics) - uncompressed	282.58 kB	+0.24%	+651 B 🔺
@sentry/nextjs (client)	50.95 kB	+0.43%	+218 B 🔺
@sentry/sveltekit (client)	46.65 kB	+0.49%	+226 B 🔺
@sentry/core/server	78.28 kB	+0.72%	+552 B 🔺
@sentry/core/browser	64.62 kB	+0.88%	+563 B 🔺
@sentry/node-core	62.7 kB	+0.53%	+328 B 🔺
@sentry/node	121.53 kB	+0.26%	+306 B 🔺
@sentry/node/import (ESM hook with diagnostics-channel injection)	69.95 kB	-	-
@sentry/node/light	50.7 kB	+0.47%	+233 B 🔺
@sentry/node - without tracing	73.05 kB	+0.5%	+358 B 🔺
@sentry/aws-serverless	83.86 kB	+0.35%	+290 B 🔺
@sentry/cloudflare (withSentry) - minified	181.52 kB	+0.5%	+900 B 🔺
@sentry/cloudflare (withSentry)	449.12 kB	+0.52%	+2.29 kB 🔺

View base workflow run

[Lms24]

dumb q but is there anything we could do to avoid having this logic hard-baked into SentrySpan? No super strong opinion, but maybe medium-strong: Ideally we can keep our SentrySpan as size-efficient as possible and rather special-case provider-emitted spans. wdyt? I might be missing something that makes this more complicated/infeasible, so feel free to disregard

[andreiborza]

@Lms24 as discussed, this adds a lot of extra code. The SentryTracerProvider doesn't instantiate spans itself, it calls core startSpan apis so there's not an easy way to instantiate spans that have this logic in them just for the tracer provider path.

This change is about 60 bytes gzipped, so I think the impact shouldn't be too bad. Also, spans should probably be finalized for core and browser as well, but that's something we can take a look at a later point.

[JPeer264]

[JPeer264]

(After looking at other functions the following is a bad idea, but I'll keep it here for food for thoughts)

q: This might be an issue for a future method when we forget to add this._frozen. Would it make sense to add an this._update() function where we update certain fields and protect that?

E.g. here we would update the startTime with this._update({ startTime: '' }), while the this._update is guarded with the this._frozen check.

[andreiborza]

I'd rather not add more code to the SentrySpan, see Lukas' original objection. I think this kind of issue of forgetting to add is easily caught by review bots nowadays.

Also, realistically, I don't think we'll expose much more api on this class.

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 8a1f780. Configure here.}

[andreiborza]

What

Seal spans created by the SentryTracerProvider once they end. After SentrySpan.end() finishes its end-of-span processing, every mutator no-ops, gated on the spanIsTracerProviderSpan brand:

• setAttribute / setAttributes
• setStatus
• updateName
• updateStartTime
• addLink / addLinks
• addEvent

Spans created directly through core (e.g. the browser SDK) are never branded, so they stay mutable.

Why

OpenTelemetry SDK spans are immutable after end() (setters no-op). The SentryTracerProvider hands native SentrySpans to OTel instrumentations as OTel spans, so they must honor that contract. Some instrumentations write to a span after end() (e.g. Next.js sets a status on a render error); without sealing, those late writes overwrite the finalized values.

This matters most once segment-span capture is deferred (#21839): the transaction snapshot is then taken on a later tick, so any late post-end() write (status, attribute, name, start time, link, or event) would be serialized into it. Sealing the span on end() keeps the finalized values intact.

Notes

• The seal applies only to provider-branded spans. The brand is set exclusively by the OTel SentryTracer, never by the browser SDK, so browser spans (including web-vitals start-time adjustments via updateStartTime) are unaffected.
• Tests in sentrySpan.test.ts cover both directions: a branded span where all mutators no-op after end(), and a non-branded span that stays mutable.

Stacked on #21839 (deferred capture / orphan emission) and #21666 (which provides the spanIsTracerProviderSpan brand). Dormant until #21680 wires the provider; no provider-branded spans exist before then.

[github-actions]

size-limit report 📦

Path	Size	% Change	Change
@sentry/browser	27.59 kB	-	-
@sentry/browser - with treeshaking flags	26.03 kB	-	-
@sentry/browser (incl. Tracing)	46.24 kB	+0.46%	+209 B 🔺
@sentry/browser (incl. Tracing + Span Streaming)	48 kB	+0.47%	+222 B 🔺
@sentry/browser (incl. Tracing, Profiling)	51.01 kB	+0.41%	+205 B 🔺
@sentry/browser (incl. Tracing, Replay)	85.49 kB	+0.27%	+224 B 🔺
@sentry/browser (incl. Tracing, Replay) - with treeshaking flags	75.1 kB	+0.31%	+225 B 🔺
@sentry/browser (incl. Tracing, Replay with Canvas)	90.19 kB	+0.26%	+232 B 🔺
@sentry/browser (incl. Tracing, Replay, Feedback)	102.84 kB	+0.23%	+226 B 🔺
@sentry/browser (incl. Feedback)	44.76 kB	-	-
@sentry/browser (incl. sendFeedback)	32.38 kB	-	-
@sentry/browser (incl. FeedbackAsync)	37.51 kB	-	-
@sentry/browser (incl. Metrics)	28.67 kB	-	-
@sentry/browser (incl. Logs)	28.91 kB	-	-
@sentry/browser (incl. Metrics & Logs)	29.59 kB	-	-
@sentry/react	29.38 kB	-	-
@sentry/react (incl. Tracing)	48.51 kB	+0.35%	+169 B 🔺
@sentry/vue	33.03 kB	+0.64%	+207 B 🔺
@sentry/vue (incl. Tracing)	48.11 kB	+0.43%	+205 B 🔺
@sentry/svelte	27.61 kB	-	-
CDN Bundle	30 kB	-	-
CDN Bundle (incl. Tracing)	48.22 kB	+0.46%	+219 B 🔺
CDN Bundle (incl. Logs, Metrics)	31.57 kB	-	-
CDN Bundle (incl. Tracing, Logs, Metrics)	49.53 kB	+0.4%	+194 B 🔺
CDN Bundle (incl. Replay, Logs, Metrics)	70.77 kB	-	-
CDN Bundle (incl. Tracing, Replay)	85.68 kB	+0.24%	+200 B 🔺
CDN Bundle (incl. Tracing, Replay, Logs, Metrics)	86.97 kB	+0.24%	+204 B 🔺
CDN Bundle (incl. Tracing, Replay, Feedback)	91.5 kB	+0.22%	+200 B 🔺
CDN Bundle (incl. Tracing, Replay, Feedback, Logs, Metrics)	92.77 kB	+0.24%	+222 B 🔺
CDN Bundle - uncompressed	89.35 kB	-	-
CDN Bundle (incl. Tracing) - uncompressed	145.92 kB	+0.45%	+649 B 🔺
CDN Bundle (incl. Logs, Metrics) - uncompressed	94.05 kB	-	-
CDN Bundle (incl. Tracing, Logs, Metrics) - uncompressed	149.89 kB	+0.44%	+649 B 🔺
CDN Bundle (incl. Replay, Logs, Metrics) - uncompressed	218.59 kB	-	-
CDN Bundle (incl. Tracing, Replay) - uncompressed	264.93 kB	+0.25%	+649 B 🔺
CDN Bundle (incl. Tracing, Replay, Logs, Metrics) - uncompressed	268.89 kB	+0.25%	+649 B 🔺
CDN Bundle (incl. Tracing, Replay, Feedback) - uncompressed	278.63 kB	+0.24%	+651 B 🔺
CDN Bundle (incl. Tracing, Replay, Feedback, Logs, Metrics) - uncompressed	282.58 kB	+0.24%	+651 B 🔺
@sentry/nextjs (client)	50.95 kB	+0.43%	+218 B 🔺
@sentry/sveltekit (client)	46.65 kB	+0.49%	+226 B 🔺
@sentry/core/server	78.28 kB	+0.72%	+552 B 🔺
@sentry/core/browser	64.62 kB	+0.88%	+563 B 🔺
@sentry/node-core	62.7 kB	+0.53%	+328 B 🔺
@sentry/node	121.53 kB	+0.26%	+306 B 🔺
@sentry/node/import (ESM hook with diagnostics-channel injection)	69.95 kB	-	-
@sentry/node/light	50.7 kB	+0.47%	+233 B 🔺
@sentry/node - without tracing	73.05 kB	+0.5%	+358 B 🔺
@sentry/aws-serverless	83.86 kB	+0.35%	+290 B 🔺
@sentry/cloudflare (withSentry) - minified	181.52 kB	+0.5%	+900 B 🔺
@sentry/cloudflare (withSentry)	449.12 kB	+0.52%	+2.29 kB 🔺

View base workflow run

[Lms24]

dumb q but is there anything we could do to avoid having this logic hard-baked into SentrySpan? No super strong opinion, but maybe medium-strong: Ideally we can keep our SentrySpan as size-efficient as possible and rather special-case provider-emitted spans. wdyt? I might be missing something that makes this more complicated/infeasible, so feel free to disregard

[andreiborza]

@Lms24 as discussed, this adds a lot of extra code. The SentryTracerProvider doesn't instantiate spans itself, it calls core startSpan apis so there's not an easy way to instantiate spans that have this logic in them just for the tracer provider path.

This change is about 60 bytes gzipped, so I think the impact shouldn't be too bad. Also, spans should probably be finalized for core and browser as well, but that's something we can take a look at a later point.

[JPeer264]

[JPeer264]

(After looking at other functions the following is a bad idea, but I'll keep it here for food for thoughts)

q: This might be an issue for a future method when we forget to add this._frozen. Would it make sense to add an this._update() function where we update certain fields and protect that?

E.g. here we would update the startTime with this._update({ startTime: '' }), while the this._update is guarded with the this._frozen check.

[andreiborza]

I'd rather not add more code to the SentrySpan, see Lukas' original objection. I think this kind of issue of forgetting to add is easily caught by review bots nowadays.

Also, realistically, I don't think we'll expose much more api on this class.

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 8a1f780. Configure here.}

[andreiborza]

What

Seal spans created by the SentryTracerProvider once they end. After SentrySpan.end() finishes its end-of-span processing, every mutator no-ops, gated on the spanIsTracerProviderSpan brand:

• setAttribute / setAttributes
• setStatus
• updateName
• updateStartTime
• addLink / addLinks
• addEvent

Spans created directly through core (e.g. the browser SDK) are never branded, so they stay mutable.

Why

OpenTelemetry SDK spans are immutable after end() (setters no-op). The SentryTracerProvider hands native SentrySpans to OTel instrumentations as OTel spans, so they must honor that contract. Some instrumentations write to a span after end() (e.g. Next.js sets a status on a render error); without sealing, those late writes overwrite the finalized values.

This matters most once segment-span capture is deferred (#21839): the transaction snapshot is then taken on a later tick, so any late post-end() write (status, attribute, name, start time, link, or event) would be serialized into it. Sealing the span on end() keeps the finalized values intact.

Notes

• The seal applies only to provider-branded spans. The brand is set exclusively by the OTel SentryTracer, never by the browser SDK, so browser spans (including web-vitals start-time adjustments via updateStartTime) are unaffected.
• Tests in sentrySpan.test.ts cover both directions: a branded span where all mutators no-op after end(), and a non-branded span that stays mutable.

Stacked on #21839 (deferred capture / orphan emission) and #21666 (which provides the spanIsTracerProviderSpan brand). Dormant until #21680 wires the provider; no provider-branded spans exist before then.

[github-actions]

size-limit report 📦

Path	Size	% Change	Change
@sentry/browser	27.59 kB	-	-
@sentry/browser - with treeshaking flags	26.03 kB	-	-
@sentry/browser (incl. Tracing)	46.24 kB	+0.46%	+209 B 🔺
@sentry/browser (incl. Tracing + Span Streaming)	48 kB	+0.47%	+222 B 🔺
@sentry/browser (incl. Tracing, Profiling)	51.01 kB	+0.41%	+205 B 🔺
@sentry/browser (incl. Tracing, Replay)	85.49 kB	+0.27%	+224 B 🔺
@sentry/browser (incl. Tracing, Replay) - with treeshaking flags	75.1 kB	+0.31%	+225 B 🔺
@sentry/browser (incl. Tracing, Replay with Canvas)	90.19 kB	+0.26%	+232 B 🔺
@sentry/browser (incl. Tracing, Replay, Feedback)	102.84 kB	+0.23%	+226 B 🔺
@sentry/browser (incl. Feedback)	44.76 kB	-	-
@sentry/browser (incl. sendFeedback)	32.38 kB	-	-
@sentry/browser (incl. FeedbackAsync)	37.51 kB	-	-
@sentry/browser (incl. Metrics)	28.67 kB	-	-
@sentry/browser (incl. Logs)	28.91 kB	-	-
@sentry/browser (incl. Metrics & Logs)	29.59 kB	-	-
@sentry/react	29.38 kB	-	-
@sentry/react (incl. Tracing)	48.51 kB	+0.35%	+169 B 🔺
@sentry/vue	33.03 kB	+0.64%	+207 B 🔺
@sentry/vue (incl. Tracing)	48.11 kB	+0.43%	+205 B 🔺
@sentry/svelte	27.61 kB	-	-
CDN Bundle	30 kB	-	-
CDN Bundle (incl. Tracing)	48.22 kB	+0.46%	+219 B 🔺
CDN Bundle (incl. Logs, Metrics)	31.57 kB	-	-
CDN Bundle (incl. Tracing, Logs, Metrics)	49.53 kB	+0.4%	+194 B 🔺
CDN Bundle (incl. Replay, Logs, Metrics)	70.77 kB	-	-
CDN Bundle (incl. Tracing, Replay)	85.68 kB	+0.24%	+200 B 🔺
CDN Bundle (incl. Tracing, Replay, Logs, Metrics)	86.97 kB	+0.24%	+204 B 🔺
CDN Bundle (incl. Tracing, Replay, Feedback)	91.5 kB	+0.22%	+200 B 🔺
CDN Bundle (incl. Tracing, Replay, Feedback, Logs, Metrics)	92.77 kB	+0.24%	+222 B 🔺
CDN Bundle - uncompressed	89.35 kB	-	-
CDN Bundle (incl. Tracing) - uncompressed	145.92 kB	+0.45%	+649 B 🔺
CDN Bundle (incl. Logs, Metrics) - uncompressed	94.05 kB	-	-
CDN Bundle (incl. Tracing, Logs, Metrics) - uncompressed	149.89 kB	+0.44%	+649 B 🔺
CDN Bundle (incl. Replay, Logs, Metrics) - uncompressed	218.59 kB	-	-
CDN Bundle (incl. Tracing, Replay) - uncompressed	264.93 kB	+0.25%	+649 B 🔺
CDN Bundle (incl. Tracing, Replay, Logs, Metrics) - uncompressed	268.89 kB	+0.25%	+649 B 🔺
CDN Bundle (incl. Tracing, Replay, Feedback) - uncompressed	278.63 kB	+0.24%	+651 B 🔺
CDN Bundle (incl. Tracing, Replay, Feedback, Logs, Metrics) - uncompressed	282.58 kB	+0.24%	+651 B 🔺
@sentry/nextjs (client)	50.95 kB	+0.43%	+218 B 🔺
@sentry/sveltekit (client)	46.65 kB	+0.49%	+226 B 🔺
@sentry/core/server	78.28 kB	+0.72%	+552 B 🔺
@sentry/core/browser	64.62 kB	+0.88%	+563 B 🔺
@sentry/node-core	62.7 kB	+0.53%	+328 B 🔺
@sentry/node	121.53 kB	+0.26%	+306 B 🔺
@sentry/node/import (ESM hook with diagnostics-channel injection)	69.95 kB	-	-
@sentry/node/light	50.7 kB	+0.47%	+233 B 🔺
@sentry/node - without tracing	73.05 kB	+0.5%	+358 B 🔺
@sentry/aws-serverless	83.86 kB	+0.35%	+290 B 🔺
@sentry/cloudflare (withSentry) - minified	181.52 kB	+0.5%	+900 B 🔺
@sentry/cloudflare (withSentry)	449.12 kB	+0.52%	+2.29 kB 🔺

View base workflow run

[Lms24]

dumb q but is there anything we could do to avoid having this logic hard-baked into SentrySpan? No super strong opinion, but maybe medium-strong: Ideally we can keep our SentrySpan as size-efficient as possible and rather special-case provider-emitted spans. wdyt? I might be missing something that makes this more complicated/infeasible, so feel free to disregard

[andreiborza]

@Lms24 as discussed, this adds a lot of extra code. The SentryTracerProvider doesn't instantiate spans itself, it calls core startSpan apis so there's not an easy way to instantiate spans that have this logic in them just for the tracer provider path.

This change is about 60 bytes gzipped, so I think the impact shouldn't be too bad. Also, spans should probably be finalized for core and browser as well, but that's something we can take a look at a later point.

[JPeer264]

[JPeer264]

(After looking at other functions the following is a bad idea, but I'll keep it here for food for thoughts)

q: This might be an issue for a future method when we forget to add this._frozen. Would it make sense to add an this._update() function where we update certain fields and protect that?

E.g. here we would update the startTime with this._update({ startTime: '' }), while the this._update is guarded with the this._frozen check.

[andreiborza]

I'd rather not add more code to the SentrySpan, see Lukas' original objection. I think this kind of issue of forgetting to add is easily caught by review bots nowadays.

Also, realistically, I don't think we'll expose much more api on this class.

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 8a1f780. Configure here.}