feat(core): Always flush streamed span traces after segment end by default

[mydea]

The browser (browserSpanStreaming.ts) and server (spanStreaming.ts) span streaming integrations were near-identical: the afterSpanEnd buffering was byte-for-byte the same, and they only differed in the eager-flush trigger. This collapses them into a single core integration, and makes flushing a trace shortly after its segment span ends the default for all runtimes, browser and server alike.

Both install sites now call spanStreamingIntegration() with no arguments: browserSpanApi._INTERNAL_ensureBrowserSpanStreaming and ServerRuntimeClient share one behavior. A trace is flushed:

• eagerly on flushTraceSpans (the Cloudflare drain),
• 500ms after its segment span ends, and
• otherwise on the SpanBuffer's own timeout/size thresholds.

Why default segment-end flushing on for the server too

Previously the server relied solely on the buffer thresholds and only the browser flushed on segment end, to avoid the server emitting more, smaller envelopes and to keep the browser's 500ms timer from holding the Node event loop open. The event-loop concern is already handled by safeUnref on the timer (a no-op in the browser), so there's no longer a reason to gate the segment-end path by runtime — flushing traces timely once their segment ends is the behavior we want everywhere.

The flushOnSegmentEnd option is retained (now defaulting to true) so a runtime can still opt out and fall back to threshold-only flushing.

Why keep it in core rather than moving to browser-utils/server-utils

The integrations are consumed internally by core — ServerRuntimeClient auto-adds it, and browserSpanApi/idleSpan auto-install it (a deliberate tree-shaking indirection). Since browser-utils and server-utils both depend on @sentry/core, core cannot import back from them without a circular dependency. Collapsing in-core sidesteps that entirely.

Export change

The integration now lives in shared-exports as a single shared symbol (star-exported by all entries) instead of being duplicated in browser-exports and server-exports. Previously the two entries resolved to different symbols, making the name an ambiguous star export that index.ts disambiguated with an explicit re-export. Now that both resolve to the same symbol, that explicit line collided with the star exports (leaving the root namespace undefined) and is removed. The startSpan/startInactiveSpan/startSpanManual disambiguation stays, as those remain genuinely distinct browser/server variants.

[github-actions]

size-limit report 📦

Path	Size	% Change	Change
@sentry/browser	28.56 kB	-	-
@sentry/browser - with treeshaking flags	26.92 kB	-	-
@sentry/browser - with treeshaking flags tracing without tracing	26.82 kB	-	-
@sentry/browser (incl. Tracing)	48.72 kB	+0.09%	+40 B 🔺
@sentry/browser (incl. Tracing + Span Streaming)	48.74 kB	+0.08%	+36 B 🔺
@sentry/browser (incl. Tracing, Profiling)	51.66 kB	+0.08%	+37 B 🔺
@sentry/browser (incl. Tracing, Replay)	88.19 kB	+0.05%	+38 B 🔺
@sentry/browser (incl. Tracing, Replay) - with treeshaking flags	77.6 kB	+0.06%	+39 B 🔺
@sentry/browser (incl. Tracing, Replay with Canvas)	92.88 kB	+0.04%	+35 B 🔺
@sentry/browser (incl. Tracing, Replay, Feedback)	105.83 kB	+0.04%	+39 B 🔺
@sentry/browser (incl. Feedback)	46.05 kB	-	-
@sentry/browser (incl. sendFeedback)	33.62 kB	-	-
@sentry/browser (incl. FeedbackAsync)	38.73 kB	-	-
@sentry/browser (incl. Metrics)	29.51 kB	-	-
@sentry/browser (incl. Logs)	29.8 kB	-	-
@sentry/browser (incl. Metrics & Logs)	30.43 kB	-	-
@sentry/react	30.3 kB	-	-
@sentry/react (incl. Tracing)	50.93 kB	+0.07%	+32 B 🔺
@sentry/vue	35.73 kB	+0.11%	+39 B 🔺
@sentry/vue (incl. Tracing)	50.97 kB	+0.08%	+38 B 🔺
@sentry/svelte	28.59 kB	-	-
CDN Bundle	30.35 kB	-	-
CDN Bundle (incl. Tracing)	49.32 kB	+0.06%	+25 B 🔺
CDN Bundle (incl. Logs, Metrics)	32.58 kB	-	-
CDN Bundle (incl. Tracing, Logs, Metrics)	51.21 kB	+0.06%	+26 B 🔺
CDN Bundle (incl. Replay, Logs, Metrics)	73.17 kB	-	-
CDN Bundle (incl. Tracing, Replay)	86.82 kB	+0.04%	+27 B 🔺
CDN Bundle (incl. Tracing, Replay, Logs, Metrics)	88.69 kB	+0.03%	+26 B 🔺
CDN Bundle (incl. Tracing, Replay, Feedback)	92.74 kB	+0.03%	+27 B 🔺
CDN Bundle (incl. Tracing, Replay, Feedback, Logs, Metrics)	94.61 kB	+0.03%	+25 B 🔺
CDN Bundle - uncompressed	89.95 kB	-	-
CDN Bundle (incl. Tracing) - uncompressed	147.05 kB	+0.07%	+89 B 🔺
CDN Bundle (incl. Logs, Metrics) - uncompressed	96.24 kB	-	-
CDN Bundle (incl. Tracing, Logs, Metrics) - uncompressed	152.74 kB	+0.06%	+89 B 🔺
CDN Bundle (incl. Replay, Logs, Metrics) - uncompressed	225.41 kB	-	-
CDN Bundle (incl. Tracing, Replay) - uncompressed	266.55 kB	+0.04%	+89 B 🔺
CDN Bundle (incl. Tracing, Replay, Logs, Metrics) - uncompressed	272.22 kB	+0.04%	+89 B 🔺
CDN Bundle (incl. Tracing, Replay, Feedback) - uncompressed	280.25 kB	+0.04%	+89 B 🔺
CDN Bundle (incl. Tracing, Replay, Feedback, Logs, Metrics) - uncompressed	285.92 kB	+0.04%	+89 B 🔺
@sentry/nextjs (client)	53.5 kB	+0.06%	+28 B 🔺
@sentry/sveltekit (client)	49.16 kB	+0.06%	+27 B 🔺
@sentry/core/server	65.47 kB	+0.04%	+22 B 🔺
@sentry/core/browser	51.87 kB	+0.06%	+29 B 🔺
@sentry/node	123.25 kB	+0.05%	+52 B 🔺
@sentry/node/import (ESM hook with diagnostics-channel injection)	85.23 kB	-	-
@sentry/node - without tracing	87.75 kB	+0.04%	+27 B 🔺
@sentry/node - without channel injection	102.92 kB	+0.06%	+59 B 🔺
@sentry/aws-serverless	95.95 kB	+0.08%	+68 B 🔺
@sentry/cloudflare (withSentry) - minified	200.65 kB	+0.08%	+143 B 🔺
@sentry/cloudflare (withSentry)	499.13 kB	+0.08%	+367 B 🔺

View base workflow run

[Lms24]

I think we can do something better here which is what we decided on last week but I didn't have time to implement yet: Let's just always flush at segment end (with the delay), regardless of environment.

In Python, we already made that change after noticing that the 5s flushing interval accumulates a lot of memory in high-throughput environments. Since we make one request per trace anyway, the number of requests shouldn't be drastically higher.

That is, as long as we can expect that traces are generally well-formed (i.e. child spans ending before their segment span). For malformed traces, with long-running child spans we would increase the request count. I think this is a fine tradeoff IMHO.

If you have (or anyone else has) concerns about this, I'd prefer keeping the two integrations separate because the merge increases bundle size for the browser version. Which was the reason why I opted against combining them initially.

[mydea]

I think we can do something better here which is what we decided on last week but I didn't have time to implement yet: Let's just always flush at segment end (with the delay), regardless of environment.

In Python, we already made that change after noticing that the 5s flushing interval accumulates a lot of memory in high-throughput environments. Since we make one request per trace anyway, the number of requests shouldn't be drastically higher.

That is, as long as we can expect that traces are generally well-formed (i.e. child spans ending before their segment span). For malformed traces, with long-running child spans we would increase the request count. I think this is a fine tradeoff IMHO.

If you have (or anyone else has) concerns about this, I'd prefer keeping the two integrations separate because the merge increases bundle size for the browser version. Which was the reason why I opted against combining them initially.

sounds good to me, so I'll just change this so that the default for flushing is true I'd say, so you can still opt out?

[Lms24]

Thanks for reworking this!

Small positive side-effect for our tests: Span streaming tests should now run faster, given we flush way more quickly.

[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 5f6ffb5. Configure here.}

[cursor]

Types drop public integration export

Medium Severity

Removing the explicit spanStreamingIntegration re-export from framework index.types.ts files drops it from the public type surface. TypeScript export * from both client and server omits colliding names, so consumers of packages such as @sentry/astro and @sentry/nextjs can no longer import it. This is flagged because the review rules treat removal of a publicly exported function without a deprecation notice as a breaking change. The same explicit re-export is still required for other shared core symbols such as withStaticSpan.

Additional Locations (2)

• packages/nextjs/src/index.types.ts#L22-L36
• packages/nuxt/src/index.types.ts#L15-L24

^{Triggered by project rule: PR Review Guidelines for Cursor Bot}

^{Reviewed by Cursor Bugbot for commit 5f6ffb5. Configure here.}

[mydea]

this is fine

[mydea]

The browser (browserSpanStreaming.ts) and server (spanStreaming.ts) span streaming integrations were near-identical: the afterSpanEnd buffering was byte-for-byte the same, and they only differed in the eager-flush trigger. This collapses them into a single core integration, and makes flushing a trace shortly after its segment span ends the default for all runtimes, browser and server alike.

Both install sites now call spanStreamingIntegration() with no arguments: browserSpanApi._INTERNAL_ensureBrowserSpanStreaming and ServerRuntimeClient share one behavior. A trace is flushed:

• eagerly on flushTraceSpans (the Cloudflare drain),
• 500ms after its segment span ends, and
• otherwise on the SpanBuffer's own timeout/size thresholds.

Why default segment-end flushing on for the server too

Previously the server relied solely on the buffer thresholds and only the browser flushed on segment end, to avoid the server emitting more, smaller envelopes and to keep the browser's 500ms timer from holding the Node event loop open. The event-loop concern is already handled by safeUnref on the timer (a no-op in the browser), so there's no longer a reason to gate the segment-end path by runtime — flushing traces timely once their segment ends is the behavior we want everywhere.

The flushOnSegmentEnd option is retained (now defaulting to true) so a runtime can still opt out and fall back to threshold-only flushing.

Why keep it in core rather than moving to browser-utils/server-utils

The integrations are consumed internally by core — ServerRuntimeClient auto-adds it, and browserSpanApi/idleSpan auto-install it (a deliberate tree-shaking indirection). Since browser-utils and server-utils both depend on @sentry/core, core cannot import back from them without a circular dependency. Collapsing in-core sidesteps that entirely.

Export change

The integration now lives in shared-exports as a single shared symbol (star-exported by all entries) instead of being duplicated in browser-exports and server-exports. Previously the two entries resolved to different symbols, making the name an ambiguous star export that index.ts disambiguated with an explicit re-export. Now that both resolve to the same symbol, that explicit line collided with the star exports (leaving the root namespace undefined) and is removed. The startSpan/startInactiveSpan/startSpanManual disambiguation stays, as those remain genuinely distinct browser/server variants.

[github-actions]

size-limit report 📦

Path	Size	% Change	Change
@sentry/browser	28.56 kB	-	-
@sentry/browser - with treeshaking flags	26.92 kB	-	-
@sentry/browser - with treeshaking flags tracing without tracing	26.82 kB	-	-
@sentry/browser (incl. Tracing)	48.72 kB	+0.09%	+40 B 🔺
@sentry/browser (incl. Tracing + Span Streaming)	48.74 kB	+0.08%	+36 B 🔺
@sentry/browser (incl. Tracing, Profiling)	51.66 kB	+0.08%	+37 B 🔺
@sentry/browser (incl. Tracing, Replay)	88.19 kB	+0.05%	+38 B 🔺
@sentry/browser (incl. Tracing, Replay) - with treeshaking flags	77.6 kB	+0.06%	+39 B 🔺
@sentry/browser (incl. Tracing, Replay with Canvas)	92.88 kB	+0.04%	+35 B 🔺
@sentry/browser (incl. Tracing, Replay, Feedback)	105.83 kB	+0.04%	+39 B 🔺
@sentry/browser (incl. Feedback)	46.05 kB	-	-
@sentry/browser (incl. sendFeedback)	33.62 kB	-	-
@sentry/browser (incl. FeedbackAsync)	38.73 kB	-	-
@sentry/browser (incl. Metrics)	29.51 kB	-	-
@sentry/browser (incl. Logs)	29.8 kB	-	-
@sentry/browser (incl. Metrics & Logs)	30.43 kB	-	-
@sentry/react	30.3 kB	-	-
@sentry/react (incl. Tracing)	50.93 kB	+0.07%	+32 B 🔺
@sentry/vue	35.73 kB	+0.11%	+39 B 🔺
@sentry/vue (incl. Tracing)	50.97 kB	+0.08%	+38 B 🔺
@sentry/svelte	28.59 kB	-	-
CDN Bundle	30.35 kB	-	-
CDN Bundle (incl. Tracing)	49.32 kB	+0.06%	+25 B 🔺
CDN Bundle (incl. Logs, Metrics)	32.58 kB	-	-
CDN Bundle (incl. Tracing, Logs, Metrics)	51.21 kB	+0.06%	+26 B 🔺
CDN Bundle (incl. Replay, Logs, Metrics)	73.17 kB	-	-
CDN Bundle (incl. Tracing, Replay)	86.82 kB	+0.04%	+27 B 🔺
CDN Bundle (incl. Tracing, Replay, Logs, Metrics)	88.69 kB	+0.03%	+26 B 🔺
CDN Bundle (incl. Tracing, Replay, Feedback)	92.74 kB	+0.03%	+27 B 🔺
CDN Bundle (incl. Tracing, Replay, Feedback, Logs, Metrics)	94.61 kB	+0.03%	+25 B 🔺
CDN Bundle - uncompressed	89.95 kB	-	-
CDN Bundle (incl. Tracing) - uncompressed	147.05 kB	+0.07%	+89 B 🔺
CDN Bundle (incl. Logs, Metrics) - uncompressed	96.24 kB	-	-
CDN Bundle (incl. Tracing, Logs, Metrics) - uncompressed	152.74 kB	+0.06%	+89 B 🔺
CDN Bundle (incl. Replay, Logs, Metrics) - uncompressed	225.41 kB	-	-
CDN Bundle (incl. Tracing, Replay) - uncompressed	266.55 kB	+0.04%	+89 B 🔺
CDN Bundle (incl. Tracing, Replay, Logs, Metrics) - uncompressed	272.22 kB	+0.04%	+89 B 🔺
CDN Bundle (incl. Tracing, Replay, Feedback) - uncompressed	280.25 kB	+0.04%	+89 B 🔺
CDN Bundle (incl. Tracing, Replay, Feedback, Logs, Metrics) - uncompressed	285.92 kB	+0.04%	+89 B 🔺
@sentry/nextjs (client)	53.5 kB	+0.06%	+28 B 🔺
@sentry/sveltekit (client)	49.16 kB	+0.06%	+27 B 🔺
@sentry/core/server	65.47 kB	+0.04%	+22 B 🔺
@sentry/core/browser	51.87 kB	+0.06%	+29 B 🔺
@sentry/node	123.25 kB	+0.05%	+52 B 🔺
@sentry/node/import (ESM hook with diagnostics-channel injection)	85.23 kB	-	-
@sentry/node - without tracing	87.75 kB	+0.04%	+27 B 🔺
@sentry/node - without channel injection	102.92 kB	+0.06%	+59 B 🔺
@sentry/aws-serverless	95.95 kB	+0.08%	+68 B 🔺
@sentry/cloudflare (withSentry) - minified	200.65 kB	+0.08%	+143 B 🔺
@sentry/cloudflare (withSentry)	499.13 kB	+0.08%	+367 B 🔺

View base workflow run

[Lms24]

I think we can do something better here which is what we decided on last week but I didn't have time to implement yet: Let's just always flush at segment end (with the delay), regardless of environment.

In Python, we already made that change after noticing that the 5s flushing interval accumulates a lot of memory in high-throughput environments. Since we make one request per trace anyway, the number of requests shouldn't be drastically higher.

That is, as long as we can expect that traces are generally well-formed (i.e. child spans ending before their segment span). For malformed traces, with long-running child spans we would increase the request count. I think this is a fine tradeoff IMHO.

If you have (or anyone else has) concerns about this, I'd prefer keeping the two integrations separate because the merge increases bundle size for the browser version. Which was the reason why I opted against combining them initially.

[mydea]

I think we can do something better here which is what we decided on last week but I didn't have time to implement yet: Let's just always flush at segment end (with the delay), regardless of environment.

In Python, we already made that change after noticing that the 5s flushing interval accumulates a lot of memory in high-throughput environments. Since we make one request per trace anyway, the number of requests shouldn't be drastically higher.

That is, as long as we can expect that traces are generally well-formed (i.e. child spans ending before their segment span). For malformed traces, with long-running child spans we would increase the request count. I think this is a fine tradeoff IMHO.

If you have (or anyone else has) concerns about this, I'd prefer keeping the two integrations separate because the merge increases bundle size for the browser version. Which was the reason why I opted against combining them initially.

sounds good to me, so I'll just change this so that the default for flushing is true I'd say, so you can still opt out?

[Lms24]

Thanks for reworking this!

Small positive side-effect for our tests: Span streaming tests should now run faster, given we flush way more quickly.

[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 5f6ffb5. Configure here.}

[cursor]

Types drop public integration export

Medium Severity

Removing the explicit spanStreamingIntegration re-export from framework index.types.ts files drops it from the public type surface. TypeScript export * from both client and server omits colliding names, so consumers of packages such as @sentry/astro and @sentry/nextjs can no longer import it. This is flagged because the review rules treat removal of a publicly exported function without a deprecation notice as a breaking change. The same explicit re-export is still required for other shared core symbols such as withStaticSpan.

Additional Locations (2)

• packages/nextjs/src/index.types.ts#L22-L36
• packages/nuxt/src/index.types.ts#L15-L24

^{Triggered by project rule: PR Review Guidelines for Cursor Bot}

^{Reviewed by Cursor Bugbot for commit 5f6ffb5. Configure here.}

[mydea]

this is fine

[mydea]

The browser (browserSpanStreaming.ts) and server (spanStreaming.ts) span streaming integrations were near-identical: the afterSpanEnd buffering was byte-for-byte the same, and they only differed in the eager-flush trigger. This collapses them into a single core integration, and makes flushing a trace shortly after its segment span ends the default for all runtimes, browser and server alike.

Both install sites now call spanStreamingIntegration() with no arguments: browserSpanApi._INTERNAL_ensureBrowserSpanStreaming and ServerRuntimeClient share one behavior. A trace is flushed:

• eagerly on flushTraceSpans (the Cloudflare drain),
• 500ms after its segment span ends, and
• otherwise on the SpanBuffer's own timeout/size thresholds.

Why default segment-end flushing on for the server too

Previously the server relied solely on the buffer thresholds and only the browser flushed on segment end, to avoid the server emitting more, smaller envelopes and to keep the browser's 500ms timer from holding the Node event loop open. The event-loop concern is already handled by safeUnref on the timer (a no-op in the browser), so there's no longer a reason to gate the segment-end path by runtime — flushing traces timely once their segment ends is the behavior we want everywhere.

The flushOnSegmentEnd option is retained (now defaulting to true) so a runtime can still opt out and fall back to threshold-only flushing.

Why keep it in core rather than moving to browser-utils/server-utils

The integrations are consumed internally by core — ServerRuntimeClient auto-adds it, and browserSpanApi/idleSpan auto-install it (a deliberate tree-shaking indirection). Since browser-utils and server-utils both depend on @sentry/core, core cannot import back from them without a circular dependency. Collapsing in-core sidesteps that entirely.

Export change

The integration now lives in shared-exports as a single shared symbol (star-exported by all entries) instead of being duplicated in browser-exports and server-exports. Previously the two entries resolved to different symbols, making the name an ambiguous star export that index.ts disambiguated with an explicit re-export. Now that both resolve to the same symbol, that explicit line collided with the star exports (leaving the root namespace undefined) and is removed. The startSpan/startInactiveSpan/startSpanManual disambiguation stays, as those remain genuinely distinct browser/server variants.

[github-actions]

size-limit report 📦

Path	Size	% Change	Change
@sentry/browser	28.56 kB	-	-
@sentry/browser - with treeshaking flags	26.92 kB	-	-
@sentry/browser - with treeshaking flags tracing without tracing	26.82 kB	-	-
@sentry/browser (incl. Tracing)	48.72 kB	+0.09%	+40 B 🔺
@sentry/browser (incl. Tracing + Span Streaming)	48.74 kB	+0.08%	+36 B 🔺
@sentry/browser (incl. Tracing, Profiling)	51.66 kB	+0.08%	+37 B 🔺
@sentry/browser (incl. Tracing, Replay)	88.19 kB	+0.05%	+38 B 🔺
@sentry/browser (incl. Tracing, Replay) - with treeshaking flags	77.6 kB	+0.06%	+39 B 🔺
@sentry/browser (incl. Tracing, Replay with Canvas)	92.88 kB	+0.04%	+35 B 🔺
@sentry/browser (incl. Tracing, Replay, Feedback)	105.83 kB	+0.04%	+39 B 🔺
@sentry/browser (incl. Feedback)	46.05 kB	-	-
@sentry/browser (incl. sendFeedback)	33.62 kB	-	-
@sentry/browser (incl. FeedbackAsync)	38.73 kB	-	-
@sentry/browser (incl. Metrics)	29.51 kB	-	-
@sentry/browser (incl. Logs)	29.8 kB	-	-
@sentry/browser (incl. Metrics & Logs)	30.43 kB	-	-
@sentry/react	30.3 kB	-	-
@sentry/react (incl. Tracing)	50.93 kB	+0.07%	+32 B 🔺
@sentry/vue	35.73 kB	+0.11%	+39 B 🔺
@sentry/vue (incl. Tracing)	50.97 kB	+0.08%	+38 B 🔺
@sentry/svelte	28.59 kB	-	-
CDN Bundle	30.35 kB	-	-
CDN Bundle (incl. Tracing)	49.32 kB	+0.06%	+25 B 🔺
CDN Bundle (incl. Logs, Metrics)	32.58 kB	-	-
CDN Bundle (incl. Tracing, Logs, Metrics)	51.21 kB	+0.06%	+26 B 🔺
CDN Bundle (incl. Replay, Logs, Metrics)	73.17 kB	-	-
CDN Bundle (incl. Tracing, Replay)	86.82 kB	+0.04%	+27 B 🔺
CDN Bundle (incl. Tracing, Replay, Logs, Metrics)	88.69 kB	+0.03%	+26 B 🔺
CDN Bundle (incl. Tracing, Replay, Feedback)	92.74 kB	+0.03%	+27 B 🔺
CDN Bundle (incl. Tracing, Replay, Feedback, Logs, Metrics)	94.61 kB	+0.03%	+25 B 🔺
CDN Bundle - uncompressed	89.95 kB	-	-
CDN Bundle (incl. Tracing) - uncompressed	147.05 kB	+0.07%	+89 B 🔺
CDN Bundle (incl. Logs, Metrics) - uncompressed	96.24 kB	-	-
CDN Bundle (incl. Tracing, Logs, Metrics) - uncompressed	152.74 kB	+0.06%	+89 B 🔺
CDN Bundle (incl. Replay, Logs, Metrics) - uncompressed	225.41 kB	-	-
CDN Bundle (incl. Tracing, Replay) - uncompressed	266.55 kB	+0.04%	+89 B 🔺
CDN Bundle (incl. Tracing, Replay, Logs, Metrics) - uncompressed	272.22 kB	+0.04%	+89 B 🔺
CDN Bundle (incl. Tracing, Replay, Feedback) - uncompressed	280.25 kB	+0.04%	+89 B 🔺
CDN Bundle (incl. Tracing, Replay, Feedback, Logs, Metrics) - uncompressed	285.92 kB	+0.04%	+89 B 🔺
@sentry/nextjs (client)	53.5 kB	+0.06%	+28 B 🔺
@sentry/sveltekit (client)	49.16 kB	+0.06%	+27 B 🔺
@sentry/core/server	65.47 kB	+0.04%	+22 B 🔺
@sentry/core/browser	51.87 kB	+0.06%	+29 B 🔺
@sentry/node	123.25 kB	+0.05%	+52 B 🔺
@sentry/node/import (ESM hook with diagnostics-channel injection)	85.23 kB	-	-
@sentry/node - without tracing	87.75 kB	+0.04%	+27 B 🔺
@sentry/node - without channel injection	102.92 kB	+0.06%	+59 B 🔺
@sentry/aws-serverless	95.95 kB	+0.08%	+68 B 🔺
@sentry/cloudflare (withSentry) - minified	200.65 kB	+0.08%	+143 B 🔺
@sentry/cloudflare (withSentry)	499.13 kB	+0.08%	+367 B 🔺

View base workflow run

[Lms24]

I think we can do something better here which is what we decided on last week but I didn't have time to implement yet: Let's just always flush at segment end (with the delay), regardless of environment.

In Python, we already made that change after noticing that the 5s flushing interval accumulates a lot of memory in high-throughput environments. Since we make one request per trace anyway, the number of requests shouldn't be drastically higher.

That is, as long as we can expect that traces are generally well-formed (i.e. child spans ending before their segment span). For malformed traces, with long-running child spans we would increase the request count. I think this is a fine tradeoff IMHO.

If you have (or anyone else has) concerns about this, I'd prefer keeping the two integrations separate because the merge increases bundle size for the browser version. Which was the reason why I opted against combining them initially.

[mydea]

I think we can do something better here which is what we decided on last week but I didn't have time to implement yet: Let's just always flush at segment end (with the delay), regardless of environment.

In Python, we already made that change after noticing that the 5s flushing interval accumulates a lot of memory in high-throughput environments. Since we make one request per trace anyway, the number of requests shouldn't be drastically higher.

That is, as long as we can expect that traces are generally well-formed (i.e. child spans ending before their segment span). For malformed traces, with long-running child spans we would increase the request count. I think this is a fine tradeoff IMHO.

If you have (or anyone else has) concerns about this, I'd prefer keeping the two integrations separate because the merge increases bundle size for the browser version. Which was the reason why I opted against combining them initially.

sounds good to me, so I'll just change this so that the default for flushing is true I'd say, so you can still opt out?

[Lms24]

Thanks for reworking this!

Small positive side-effect for our tests: Span streaming tests should now run faster, given we flush way more quickly.

[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 5f6ffb5. Configure here.}

[cursor]

Types drop public integration export

Medium Severity

Removing the explicit spanStreamingIntegration re-export from framework index.types.ts files drops it from the public type surface. TypeScript export * from both client and server omits colliding names, so consumers of packages such as @sentry/astro and @sentry/nextjs can no longer import it. This is flagged because the review rules treat removal of a publicly exported function without a deprecation notice as a breaking change. The same explicit re-export is still required for other shared core symbols such as withStaticSpan.

Additional Locations (2)

• packages/nextjs/src/index.types.ts#L22-L36
• packages/nuxt/src/index.types.ts#L15-L24

^{Triggered by project rule: PR Review Guidelines for Cursor Bot}

^{Reviewed by Cursor Bugbot for commit 5f6ffb5. Configure here.}

[mydea]

this is fine

[mydea]

The browser (browserSpanStreaming.ts) and server (spanStreaming.ts) span streaming integrations were near-identical: the afterSpanEnd buffering was byte-for-byte the same, and they only differed in the eager-flush trigger. This collapses them into a single core integration, and makes flushing a trace shortly after its segment span ends the default for all runtimes, browser and server alike.

Both install sites now call spanStreamingIntegration() with no arguments: browserSpanApi._INTERNAL_ensureBrowserSpanStreaming and ServerRuntimeClient share one behavior. A trace is flushed:

• eagerly on flushTraceSpans (the Cloudflare drain),
• 500ms after its segment span ends, and
• otherwise on the SpanBuffer's own timeout/size thresholds.

Why default segment-end flushing on for the server too

Previously the server relied solely on the buffer thresholds and only the browser flushed on segment end, to avoid the server emitting more, smaller envelopes and to keep the browser's 500ms timer from holding the Node event loop open. The event-loop concern is already handled by safeUnref on the timer (a no-op in the browser), so there's no longer a reason to gate the segment-end path by runtime — flushing traces timely once their segment ends is the behavior we want everywhere.

The flushOnSegmentEnd option is retained (now defaulting to true) so a runtime can still opt out and fall back to threshold-only flushing.

Why keep it in core rather than moving to browser-utils/server-utils

The integrations are consumed internally by core — ServerRuntimeClient auto-adds it, and browserSpanApi/idleSpan auto-install it (a deliberate tree-shaking indirection). Since browser-utils and server-utils both depend on @sentry/core, core cannot import back from them without a circular dependency. Collapsing in-core sidesteps that entirely.

Export change

The integration now lives in shared-exports as a single shared symbol (star-exported by all entries) instead of being duplicated in browser-exports and server-exports. Previously the two entries resolved to different symbols, making the name an ambiguous star export that index.ts disambiguated with an explicit re-export. Now that both resolve to the same symbol, that explicit line collided with the star exports (leaving the root namespace undefined) and is removed. The startSpan/startInactiveSpan/startSpanManual disambiguation stays, as those remain genuinely distinct browser/server variants.

[github-actions]

size-limit report 📦

Path	Size	% Change	Change
@sentry/browser	28.56 kB	-	-
@sentry/browser - with treeshaking flags	26.92 kB	-	-
@sentry/browser - with treeshaking flags tracing without tracing	26.82 kB	-	-
@sentry/browser (incl. Tracing)	48.72 kB	+0.09%	+40 B 🔺
@sentry/browser (incl. Tracing + Span Streaming)	48.74 kB	+0.08%	+36 B 🔺
@sentry/browser (incl. Tracing, Profiling)	51.66 kB	+0.08%	+37 B 🔺
@sentry/browser (incl. Tracing, Replay)	88.19 kB	+0.05%	+38 B 🔺
@sentry/browser (incl. Tracing, Replay) - with treeshaking flags	77.6 kB	+0.06%	+39 B 🔺
@sentry/browser (incl. Tracing, Replay with Canvas)	92.88 kB	+0.04%	+35 B 🔺
@sentry/browser (incl. Tracing, Replay, Feedback)	105.83 kB	+0.04%	+39 B 🔺
@sentry/browser (incl. Feedback)	46.05 kB	-	-
@sentry/browser (incl. sendFeedback)	33.62 kB	-	-
@sentry/browser (incl. FeedbackAsync)	38.73 kB	-	-
@sentry/browser (incl. Metrics)	29.51 kB	-	-
@sentry/browser (incl. Logs)	29.8 kB	-	-
@sentry/browser (incl. Metrics & Logs)	30.43 kB	-	-
@sentry/react	30.3 kB	-	-
@sentry/react (incl. Tracing)	50.93 kB	+0.07%	+32 B 🔺
@sentry/vue	35.73 kB	+0.11%	+39 B 🔺
@sentry/vue (incl. Tracing)	50.97 kB	+0.08%	+38 B 🔺
@sentry/svelte	28.59 kB	-	-
CDN Bundle	30.35 kB	-	-
CDN Bundle (incl. Tracing)	49.32 kB	+0.06%	+25 B 🔺
CDN Bundle (incl. Logs, Metrics)	32.58 kB	-	-
CDN Bundle (incl. Tracing, Logs, Metrics)	51.21 kB	+0.06%	+26 B 🔺
CDN Bundle (incl. Replay, Logs, Metrics)	73.17 kB	-	-
CDN Bundle (incl. Tracing, Replay)	86.82 kB	+0.04%	+27 B 🔺
CDN Bundle (incl. Tracing, Replay, Logs, Metrics)	88.69 kB	+0.03%	+26 B 🔺
CDN Bundle (incl. Tracing, Replay, Feedback)	92.74 kB	+0.03%	+27 B 🔺
CDN Bundle (incl. Tracing, Replay, Feedback, Logs, Metrics)	94.61 kB	+0.03%	+25 B 🔺
CDN Bundle - uncompressed	89.95 kB	-	-
CDN Bundle (incl. Tracing) - uncompressed	147.05 kB	+0.07%	+89 B 🔺
CDN Bundle (incl. Logs, Metrics) - uncompressed	96.24 kB	-	-
CDN Bundle (incl. Tracing, Logs, Metrics) - uncompressed	152.74 kB	+0.06%	+89 B 🔺
CDN Bundle (incl. Replay, Logs, Metrics) - uncompressed	225.41 kB	-	-
CDN Bundle (incl. Tracing, Replay) - uncompressed	266.55 kB	+0.04%	+89 B 🔺
CDN Bundle (incl. Tracing, Replay, Logs, Metrics) - uncompressed	272.22 kB	+0.04%	+89 B 🔺
CDN Bundle (incl. Tracing, Replay, Feedback) - uncompressed	280.25 kB	+0.04%	+89 B 🔺
CDN Bundle (incl. Tracing, Replay, Feedback, Logs, Metrics) - uncompressed	285.92 kB	+0.04%	+89 B 🔺
@sentry/nextjs (client)	53.5 kB	+0.06%	+28 B 🔺
@sentry/sveltekit (client)	49.16 kB	+0.06%	+27 B 🔺
@sentry/core/server	65.47 kB	+0.04%	+22 B 🔺
@sentry/core/browser	51.87 kB	+0.06%	+29 B 🔺
@sentry/node	123.25 kB	+0.05%	+52 B 🔺
@sentry/node/import (ESM hook with diagnostics-channel injection)	85.23 kB	-	-
@sentry/node - without tracing	87.75 kB	+0.04%	+27 B 🔺
@sentry/node - without channel injection	102.92 kB	+0.06%	+59 B 🔺
@sentry/aws-serverless	95.95 kB	+0.08%	+68 B 🔺
@sentry/cloudflare (withSentry) - minified	200.65 kB	+0.08%	+143 B 🔺
@sentry/cloudflare (withSentry)	499.13 kB	+0.08%	+367 B 🔺

View base workflow run

[Lms24]

I think we can do something better here which is what we decided on last week but I didn't have time to implement yet: Let's just always flush at segment end (with the delay), regardless of environment.

In Python, we already made that change after noticing that the 5s flushing interval accumulates a lot of memory in high-throughput environments. Since we make one request per trace anyway, the number of requests shouldn't be drastically higher.

That is, as long as we can expect that traces are generally well-formed (i.e. child spans ending before their segment span). For malformed traces, with long-running child spans we would increase the request count. I think this is a fine tradeoff IMHO.

If you have (or anyone else has) concerns about this, I'd prefer keeping the two integrations separate because the merge increases bundle size for the browser version. Which was the reason why I opted against combining them initially.

[mydea]

I think we can do something better here which is what we decided on last week but I didn't have time to implement yet: Let's just always flush at segment end (with the delay), regardless of environment.

In Python, we already made that change after noticing that the 5s flushing interval accumulates a lot of memory in high-throughput environments. Since we make one request per trace anyway, the number of requests shouldn't be drastically higher.

That is, as long as we can expect that traces are generally well-formed (i.e. child spans ending before their segment span). For malformed traces, with long-running child spans we would increase the request count. I think this is a fine tradeoff IMHO.

If you have (or anyone else has) concerns about this, I'd prefer keeping the two integrations separate because the merge increases bundle size for the browser version. Which was the reason why I opted against combining them initially.

sounds good to me, so I'll just change this so that the default for flushing is true I'd say, so you can still opt out?

[Lms24]

Thanks for reworking this!

Small positive side-effect for our tests: Span streaming tests should now run faster, given we flush way more quickly.

[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 5f6ffb5. Configure here.}

[cursor]

Types drop public integration export

Medium Severity

Removing the explicit spanStreamingIntegration re-export from framework index.types.ts files drops it from the public type surface. TypeScript export * from both client and server omits colliding names, so consumers of packages such as @sentry/astro and @sentry/nextjs can no longer import it. This is flagged because the review rules treat removal of a publicly exported function without a deprecation notice as a breaking change. The same explicit re-export is still required for other shared core symbols such as withStaticSpan.

Additional Locations (2)

• packages/nextjs/src/index.types.ts#L22-L36
• packages/nuxt/src/index.types.ts#L15-L24

^{Triggered by project rule: PR Review Guidelines for Cursor Bot}

^{Reviewed by Cursor Bugbot for commit 5f6ffb5. Configure here.}

[mydea]

this is fine

[mydea]

The browser (browserSpanStreaming.ts) and server (spanStreaming.ts) span streaming integrations were near-identical: the afterSpanEnd buffering was byte-for-byte the same, and they only differed in the eager-flush trigger. This collapses them into a single core integration, and makes flushing a trace shortly after its segment span ends the default for all runtimes, browser and server alike.

Both install sites now call spanStreamingIntegration() with no arguments: browserSpanApi._INTERNAL_ensureBrowserSpanStreaming and ServerRuntimeClient share one behavior. A trace is flushed:

• eagerly on flushTraceSpans (the Cloudflare drain),
• 500ms after its segment span ends, and
• otherwise on the SpanBuffer's own timeout/size thresholds.

Why default segment-end flushing on for the server too

Previously the server relied solely on the buffer thresholds and only the browser flushed on segment end, to avoid the server emitting more, smaller envelopes and to keep the browser's 500ms timer from holding the Node event loop open. The event-loop concern is already handled by safeUnref on the timer (a no-op in the browser), so there's no longer a reason to gate the segment-end path by runtime — flushing traces timely once their segment ends is the behavior we want everywhere.

The flushOnSegmentEnd option is retained (now defaulting to true) so a runtime can still opt out and fall back to threshold-only flushing.

Why keep it in core rather than moving to browser-utils/server-utils

The integrations are consumed internally by core — ServerRuntimeClient auto-adds it, and browserSpanApi/idleSpan auto-install it (a deliberate tree-shaking indirection). Since browser-utils and server-utils both depend on @sentry/core, core cannot import back from them without a circular dependency. Collapsing in-core sidesteps that entirely.

Export change

The integration now lives in shared-exports as a single shared symbol (star-exported by all entries) instead of being duplicated in browser-exports and server-exports. Previously the two entries resolved to different symbols, making the name an ambiguous star export that index.ts disambiguated with an explicit re-export. Now that both resolve to the same symbol, that explicit line collided with the star exports (leaving the root namespace undefined) and is removed. The startSpan/startInactiveSpan/startSpanManual disambiguation stays, as those remain genuinely distinct browser/server variants.

[github-actions]

size-limit report 📦

Path	Size	% Change	Change
@sentry/browser	28.56 kB	-	-
@sentry/browser - with treeshaking flags	26.92 kB	-	-
@sentry/browser - with treeshaking flags tracing without tracing	26.82 kB	-	-
@sentry/browser (incl. Tracing)	48.72 kB	+0.09%	+40 B 🔺
@sentry/browser (incl. Tracing + Span Streaming)	48.74 kB	+0.08%	+36 B 🔺
@sentry/browser (incl. Tracing, Profiling)	51.66 kB	+0.08%	+37 B 🔺
@sentry/browser (incl. Tracing, Replay)	88.19 kB	+0.05%	+38 B 🔺
@sentry/browser (incl. Tracing, Replay) - with treeshaking flags	77.6 kB	+0.06%	+39 B 🔺
@sentry/browser (incl. Tracing, Replay with Canvas)	92.88 kB	+0.04%	+35 B 🔺
@sentry/browser (incl. Tracing, Replay, Feedback)	105.83 kB	+0.04%	+39 B 🔺
@sentry/browser (incl. Feedback)	46.05 kB	-	-
@sentry/browser (incl. sendFeedback)	33.62 kB	-	-
@sentry/browser (incl. FeedbackAsync)	38.73 kB	-	-
@sentry/browser (incl. Metrics)	29.51 kB	-	-
@sentry/browser (incl. Logs)	29.8 kB	-	-
@sentry/browser (incl. Metrics & Logs)	30.43 kB	-	-
@sentry/react	30.3 kB	-	-
@sentry/react (incl. Tracing)	50.93 kB	+0.07%	+32 B 🔺
@sentry/vue	35.73 kB	+0.11%	+39 B 🔺
@sentry/vue (incl. Tracing)	50.97 kB	+0.08%	+38 B 🔺
@sentry/svelte	28.59 kB	-	-
CDN Bundle	30.35 kB	-	-
CDN Bundle (incl. Tracing)	49.32 kB	+0.06%	+25 B 🔺
CDN Bundle (incl. Logs, Metrics)	32.58 kB	-	-
CDN Bundle (incl. Tracing, Logs, Metrics)	51.21 kB	+0.06%	+26 B 🔺
CDN Bundle (incl. Replay, Logs, Metrics)	73.17 kB	-	-
CDN Bundle (incl. Tracing, Replay)	86.82 kB	+0.04%	+27 B 🔺
CDN Bundle (incl. Tracing, Replay, Logs, Metrics)	88.69 kB	+0.03%	+26 B 🔺
CDN Bundle (incl. Tracing, Replay, Feedback)	92.74 kB	+0.03%	+27 B 🔺
CDN Bundle (incl. Tracing, Replay, Feedback, Logs, Metrics)	94.61 kB	+0.03%	+25 B 🔺
CDN Bundle - uncompressed	89.95 kB	-	-
CDN Bundle (incl. Tracing) - uncompressed	147.05 kB	+0.07%	+89 B 🔺
CDN Bundle (incl. Logs, Metrics) - uncompressed	96.24 kB	-	-
CDN Bundle (incl. Tracing, Logs, Metrics) - uncompressed	152.74 kB	+0.06%	+89 B 🔺
CDN Bundle (incl. Replay, Logs, Metrics) - uncompressed	225.41 kB	-	-
CDN Bundle (incl. Tracing, Replay) - uncompressed	266.55 kB	+0.04%	+89 B 🔺
CDN Bundle (incl. Tracing, Replay, Logs, Metrics) - uncompressed	272.22 kB	+0.04%	+89 B 🔺
CDN Bundle (incl. Tracing, Replay, Feedback) - uncompressed	280.25 kB	+0.04%	+89 B 🔺
CDN Bundle (incl. Tracing, Replay, Feedback, Logs, Metrics) - uncompressed	285.92 kB	+0.04%	+89 B 🔺
@sentry/nextjs (client)	53.5 kB	+0.06%	+28 B 🔺
@sentry/sveltekit (client)	49.16 kB	+0.06%	+27 B 🔺
@sentry/core/server	65.47 kB	+0.04%	+22 B 🔺
@sentry/core/browser	51.87 kB	+0.06%	+29 B 🔺
@sentry/node	123.25 kB	+0.05%	+52 B 🔺
@sentry/node/import (ESM hook with diagnostics-channel injection)	85.23 kB	-	-
@sentry/node - without tracing	87.75 kB	+0.04%	+27 B 🔺
@sentry/node - without channel injection	102.92 kB	+0.06%	+59 B 🔺
@sentry/aws-serverless	95.95 kB	+0.08%	+68 B 🔺
@sentry/cloudflare (withSentry) - minified	200.65 kB	+0.08%	+143 B 🔺
@sentry/cloudflare (withSentry)	499.13 kB	+0.08%	+367 B 🔺

View base workflow run

[Lms24]

I think we can do something better here which is what we decided on last week but I didn't have time to implement yet: Let's just always flush at segment end (with the delay), regardless of environment.

In Python, we already made that change after noticing that the 5s flushing interval accumulates a lot of memory in high-throughput environments. Since we make one request per trace anyway, the number of requests shouldn't be drastically higher.

That is, as long as we can expect that traces are generally well-formed (i.e. child spans ending before their segment span). For malformed traces, with long-running child spans we would increase the request count. I think this is a fine tradeoff IMHO.

If you have (or anyone else has) concerns about this, I'd prefer keeping the two integrations separate because the merge increases bundle size for the browser version. Which was the reason why I opted against combining them initially.

[mydea]

I think we can do something better here which is what we decided on last week but I didn't have time to implement yet: Let's just always flush at segment end (with the delay), regardless of environment.

In Python, we already made that change after noticing that the 5s flushing interval accumulates a lot of memory in high-throughput environments. Since we make one request per trace anyway, the number of requests shouldn't be drastically higher.

That is, as long as we can expect that traces are generally well-formed (i.e. child spans ending before their segment span). For malformed traces, with long-running child spans we would increase the request count. I think this is a fine tradeoff IMHO.

If you have (or anyone else has) concerns about this, I'd prefer keeping the two integrations separate because the merge increases bundle size for the browser version. Which was the reason why I opted against combining them initially.

sounds good to me, so I'll just change this so that the default for flushing is true I'd say, so you can still opt out?

[Lms24]

Thanks for reworking this!

Small positive side-effect for our tests: Span streaming tests should now run faster, given we flush way more quickly.

[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 5f6ffb5. Configure here.}

[cursor]

Types drop public integration export

Medium Severity

Removing the explicit spanStreamingIntegration re-export from framework index.types.ts files drops it from the public type surface. TypeScript export * from both client and server omits colliding names, so consumers of packages such as @sentry/astro and @sentry/nextjs can no longer import it. This is flagged because the review rules treat removal of a publicly exported function without a deprecation notice as a breaking change. The same explicit re-export is still required for other shared core symbols such as withStaticSpan.

Additional Locations (2)

• packages/nextjs/src/index.types.ts#L22-L36
• packages/nuxt/src/index.types.ts#L15-L24

^{Triggered by project rule: PR Review Guidelines for Cursor Bot}

^{Reviewed by Cursor Bugbot for commit 5f6ffb5. Configure here.}

[mydea]

this is fine

[mydea]

The browser (browserSpanStreaming.ts) and server (spanStreaming.ts) span streaming integrations were near-identical: the afterSpanEnd buffering was byte-for-byte the same, and they only differed in the eager-flush trigger. This collapses them into a single core integration, and makes flushing a trace shortly after its segment span ends the default for all runtimes, browser and server alike.

Both install sites now call spanStreamingIntegration() with no arguments: browserSpanApi._INTERNAL_ensureBrowserSpanStreaming and ServerRuntimeClient share one behavior. A trace is flushed:

• eagerly on flushTraceSpans (the Cloudflare drain),
• 500ms after its segment span ends, and
• otherwise on the SpanBuffer's own timeout/size thresholds.

Why default segment-end flushing on for the server too

Previously the server relied solely on the buffer thresholds and only the browser flushed on segment end, to avoid the server emitting more, smaller envelopes and to keep the browser's 500ms timer from holding the Node event loop open. The event-loop concern is already handled by safeUnref on the timer (a no-op in the browser), so there's no longer a reason to gate the segment-end path by runtime — flushing traces timely once their segment ends is the behavior we want everywhere.

The flushOnSegmentEnd option is retained (now defaulting to true) so a runtime can still opt out and fall back to threshold-only flushing.

Why keep it in core rather than moving to browser-utils/server-utils

The integrations are consumed internally by core — ServerRuntimeClient auto-adds it, and browserSpanApi/idleSpan auto-install it (a deliberate tree-shaking indirection). Since browser-utils and server-utils both depend on @sentry/core, core cannot import back from them without a circular dependency. Collapsing in-core sidesteps that entirely.

Export change

The integration now lives in shared-exports as a single shared symbol (star-exported by all entries) instead of being duplicated in browser-exports and server-exports. Previously the two entries resolved to different symbols, making the name an ambiguous star export that index.ts disambiguated with an explicit re-export. Now that both resolve to the same symbol, that explicit line collided with the star exports (leaving the root namespace undefined) and is removed. The startSpan/startInactiveSpan/startSpanManual disambiguation stays, as those remain genuinely distinct browser/server variants.

[github-actions]

size-limit report 📦

Path	Size	% Change	Change
@sentry/browser	28.56 kB	-	-
@sentry/browser - with treeshaking flags	26.92 kB	-	-
@sentry/browser - with treeshaking flags tracing without tracing	26.82 kB	-	-
@sentry/browser (incl. Tracing)	48.72 kB	+0.09%	+40 B 🔺
@sentry/browser (incl. Tracing + Span Streaming)	48.74 kB	+0.08%	+36 B 🔺
@sentry/browser (incl. Tracing, Profiling)	51.66 kB	+0.08%	+37 B 🔺
@sentry/browser (incl. Tracing, Replay)	88.19 kB	+0.05%	+38 B 🔺
@sentry/browser (incl. Tracing, Replay) - with treeshaking flags	77.6 kB	+0.06%	+39 B 🔺
@sentry/browser (incl. Tracing, Replay with Canvas)	92.88 kB	+0.04%	+35 B 🔺
@sentry/browser (incl. Tracing, Replay, Feedback)	105.83 kB	+0.04%	+39 B 🔺
@sentry/browser (incl. Feedback)	46.05 kB	-	-
@sentry/browser (incl. sendFeedback)	33.62 kB	-	-
@sentry/browser (incl. FeedbackAsync)	38.73 kB	-	-
@sentry/browser (incl. Metrics)	29.51 kB	-	-
@sentry/browser (incl. Logs)	29.8 kB	-	-
@sentry/browser (incl. Metrics & Logs)	30.43 kB	-	-
@sentry/react	30.3 kB	-	-
@sentry/react (incl. Tracing)	50.93 kB	+0.07%	+32 B 🔺
@sentry/vue	35.73 kB	+0.11%	+39 B 🔺
@sentry/vue (incl. Tracing)	50.97 kB	+0.08%	+38 B 🔺
@sentry/svelte	28.59 kB	-	-
CDN Bundle	30.35 kB	-	-
CDN Bundle (incl. Tracing)	49.32 kB	+0.06%	+25 B 🔺
CDN Bundle (incl. Logs, Metrics)	32.58 kB	-	-
CDN Bundle (incl. Tracing, Logs, Metrics)	51.21 kB	+0.06%	+26 B 🔺
CDN Bundle (incl. Replay, Logs, Metrics)	73.17 kB	-	-
CDN Bundle (incl. Tracing, Replay)	86.82 kB	+0.04%	+27 B 🔺
CDN Bundle (incl. Tracing, Replay, Logs, Metrics)	88.69 kB	+0.03%	+26 B 🔺
CDN Bundle (incl. Tracing, Replay, Feedback)	92.74 kB	+0.03%	+27 B 🔺
CDN Bundle (incl. Tracing, Replay, Feedback, Logs, Metrics)	94.61 kB	+0.03%	+25 B 🔺
CDN Bundle - uncompressed	89.95 kB	-	-
CDN Bundle (incl. Tracing) - uncompressed	147.05 kB	+0.07%	+89 B 🔺
CDN Bundle (incl. Logs, Metrics) - uncompressed	96.24 kB	-	-
CDN Bundle (incl. Tracing, Logs, Metrics) - uncompressed	152.74 kB	+0.06%	+89 B 🔺
CDN Bundle (incl. Replay, Logs, Metrics) - uncompressed	225.41 kB	-	-
CDN Bundle (incl. Tracing, Replay) - uncompressed	266.55 kB	+0.04%	+89 B 🔺
CDN Bundle (incl. Tracing, Replay, Logs, Metrics) - uncompressed	272.22 kB	+0.04%	+89 B 🔺
CDN Bundle (incl. Tracing, Replay, Feedback) - uncompressed	280.25 kB	+0.04%	+89 B 🔺
CDN Bundle (incl. Tracing, Replay, Feedback, Logs, Metrics) - uncompressed	285.92 kB	+0.04%	+89 B 🔺
@sentry/nextjs (client)	53.5 kB	+0.06%	+28 B 🔺
@sentry/sveltekit (client)	49.16 kB	+0.06%	+27 B 🔺
@sentry/core/server	65.47 kB	+0.04%	+22 B 🔺
@sentry/core/browser	51.87 kB	+0.06%	+29 B 🔺
@sentry/node	123.25 kB	+0.05%	+52 B 🔺
@sentry/node/import (ESM hook with diagnostics-channel injection)	85.23 kB	-	-
@sentry/node - without tracing	87.75 kB	+0.04%	+27 B 🔺
@sentry/node - without channel injection	102.92 kB	+0.06%	+59 B 🔺
@sentry/aws-serverless	95.95 kB	+0.08%	+68 B 🔺
@sentry/cloudflare (withSentry) - minified	200.65 kB	+0.08%	+143 B 🔺
@sentry/cloudflare (withSentry)	499.13 kB	+0.08%	+367 B 🔺

View base workflow run

[Lms24]

I think we can do something better here which is what we decided on last week but I didn't have time to implement yet: Let's just always flush at segment end (with the delay), regardless of environment.

In Python, we already made that change after noticing that the 5s flushing interval accumulates a lot of memory in high-throughput environments. Since we make one request per trace anyway, the number of requests shouldn't be drastically higher.

That is, as long as we can expect that traces are generally well-formed (i.e. child spans ending before their segment span). For malformed traces, with long-running child spans we would increase the request count. I think this is a fine tradeoff IMHO.

If you have (or anyone else has) concerns about this, I'd prefer keeping the two integrations separate because the merge increases bundle size for the browser version. Which was the reason why I opted against combining them initially.

[mydea]

I think we can do something better here which is what we decided on last week but I didn't have time to implement yet: Let's just always flush at segment end (with the delay), regardless of environment.

In Python, we already made that change after noticing that the 5s flushing interval accumulates a lot of memory in high-throughput environments. Since we make one request per trace anyway, the number of requests shouldn't be drastically higher.

That is, as long as we can expect that traces are generally well-formed (i.e. child spans ending before their segment span). For malformed traces, with long-running child spans we would increase the request count. I think this is a fine tradeoff IMHO.

If you have (or anyone else has) concerns about this, I'd prefer keeping the two integrations separate because the merge increases bundle size for the browser version. Which was the reason why I opted against combining them initially.

sounds good to me, so I'll just change this so that the default for flushing is true I'd say, so you can still opt out?

[Lms24]

Thanks for reworking this!

Small positive side-effect for our tests: Span streaming tests should now run faster, given we flush way more quickly.

[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 5f6ffb5. Configure here.}

[cursor]

Types drop public integration export

Medium Severity

Removing the explicit spanStreamingIntegration re-export from framework index.types.ts files drops it from the public type surface. TypeScript export * from both client and server omits colliding names, so consumers of packages such as @sentry/astro and @sentry/nextjs can no longer import it. This is flagged because the review rules treat removal of a publicly exported function without a deprecation notice as a breaking change. The same explicit re-export is still required for other shared core symbols such as withStaticSpan.

Additional Locations (2)

• packages/nextjs/src/index.types.ts#L22-L36
• packages/nuxt/src/index.types.ts#L15-L24

^{Triggered by project rule: PR Review Guidelines for Cursor Bot}

^{Reviewed by Cursor Bugbot for commit 5f6ffb5. Configure here.}

[mydea]

this is fine

[mydea]

The browser (browserSpanStreaming.ts) and server (spanStreaming.ts) span streaming integrations were near-identical: the afterSpanEnd buffering was byte-for-byte the same, and they only differed in the eager-flush trigger. This collapses them into a single core integration, and makes flushing a trace shortly after its segment span ends the default for all runtimes, browser and server alike.

Both install sites now call spanStreamingIntegration() with no arguments: browserSpanApi._INTERNAL_ensureBrowserSpanStreaming and ServerRuntimeClient share one behavior. A trace is flushed:

• eagerly on flushTraceSpans (the Cloudflare drain),
• 500ms after its segment span ends, and
• otherwise on the SpanBuffer's own timeout/size thresholds.

Why default segment-end flushing on for the server too

Previously the server relied solely on the buffer thresholds and only the browser flushed on segment end, to avoid the server emitting more, smaller envelopes and to keep the browser's 500ms timer from holding the Node event loop open. The event-loop concern is already handled by safeUnref on the timer (a no-op in the browser), so there's no longer a reason to gate the segment-end path by runtime — flushing traces timely once their segment ends is the behavior we want everywhere.

The flushOnSegmentEnd option is retained (now defaulting to true) so a runtime can still opt out and fall back to threshold-only flushing.

Why keep it in core rather than moving to browser-utils/server-utils

The integrations are consumed internally by core — ServerRuntimeClient auto-adds it, and browserSpanApi/idleSpan auto-install it (a deliberate tree-shaking indirection). Since browser-utils and server-utils both depend on @sentry/core, core cannot import back from them without a circular dependency. Collapsing in-core sidesteps that entirely.

Export change

The integration now lives in shared-exports as a single shared symbol (star-exported by all entries) instead of being duplicated in browser-exports and server-exports. Previously the two entries resolved to different symbols, making the name an ambiguous star export that index.ts disambiguated with an explicit re-export. Now that both resolve to the same symbol, that explicit line collided with the star exports (leaving the root namespace undefined) and is removed. The startSpan/startInactiveSpan/startSpanManual disambiguation stays, as those remain genuinely distinct browser/server variants.

[github-actions]

size-limit report 📦

Path	Size	% Change	Change
@sentry/browser	28.56 kB	-	-
@sentry/browser - with treeshaking flags	26.92 kB	-	-
@sentry/browser - with treeshaking flags tracing without tracing	26.82 kB	-	-
@sentry/browser (incl. Tracing)	48.72 kB	+0.09%	+40 B 🔺
@sentry/browser (incl. Tracing + Span Streaming)	48.74 kB	+0.08%	+36 B 🔺
@sentry/browser (incl. Tracing, Profiling)	51.66 kB	+0.08%	+37 B 🔺
@sentry/browser (incl. Tracing, Replay)	88.19 kB	+0.05%	+38 B 🔺
@sentry/browser (incl. Tracing, Replay) - with treeshaking flags	77.6 kB	+0.06%	+39 B 🔺
@sentry/browser (incl. Tracing, Replay with Canvas)	92.88 kB	+0.04%	+35 B 🔺
@sentry/browser (incl. Tracing, Replay, Feedback)	105.83 kB	+0.04%	+39 B 🔺
@sentry/browser (incl. Feedback)	46.05 kB	-	-
@sentry/browser (incl. sendFeedback)	33.62 kB	-	-
@sentry/browser (incl. FeedbackAsync)	38.73 kB	-	-
@sentry/browser (incl. Metrics)	29.51 kB	-	-
@sentry/browser (incl. Logs)	29.8 kB	-	-
@sentry/browser (incl. Metrics & Logs)	30.43 kB	-	-
@sentry/react	30.3 kB	-	-
@sentry/react (incl. Tracing)	50.93 kB	+0.07%	+32 B 🔺
@sentry/vue	35.73 kB	+0.11%	+39 B 🔺
@sentry/vue (incl. Tracing)	50.97 kB	+0.08%	+38 B 🔺
@sentry/svelte	28.59 kB	-	-
CDN Bundle	30.35 kB	-	-
CDN Bundle (incl. Tracing)	49.32 kB	+0.06%	+25 B 🔺
CDN Bundle (incl. Logs, Metrics)	32.58 kB	-	-
CDN Bundle (incl. Tracing, Logs, Metrics)	51.21 kB	+0.06%	+26 B 🔺
CDN Bundle (incl. Replay, Logs, Metrics)	73.17 kB	-	-
CDN Bundle (incl. Tracing, Replay)	86.82 kB	+0.04%	+27 B 🔺
CDN Bundle (incl. Tracing, Replay, Logs, Metrics)	88.69 kB	+0.03%	+26 B 🔺
CDN Bundle (incl. Tracing, Replay, Feedback)	92.74 kB	+0.03%	+27 B 🔺
CDN Bundle (incl. Tracing, Replay, Feedback, Logs, Metrics)	94.61 kB	+0.03%	+25 B 🔺
CDN Bundle - uncompressed	89.95 kB	-	-
CDN Bundle (incl. Tracing) - uncompressed	147.05 kB	+0.07%	+89 B 🔺
CDN Bundle (incl. Logs, Metrics) - uncompressed	96.24 kB	-	-
CDN Bundle (incl. Tracing, Logs, Metrics) - uncompressed	152.74 kB	+0.06%	+89 B 🔺
CDN Bundle (incl. Replay, Logs, Metrics) - uncompressed	225.41 kB	-	-
CDN Bundle (incl. Tracing, Replay) - uncompressed	266.55 kB	+0.04%	+89 B 🔺
CDN Bundle (incl. Tracing, Replay, Logs, Metrics) - uncompressed	272.22 kB	+0.04%	+89 B 🔺
CDN Bundle (incl. Tracing, Replay, Feedback) - uncompressed	280.25 kB	+0.04%	+89 B 🔺
CDN Bundle (incl. Tracing, Replay, Feedback, Logs, Metrics) - uncompressed	285.92 kB	+0.04%	+89 B 🔺
@sentry/nextjs (client)	53.5 kB	+0.06%	+28 B 🔺
@sentry/sveltekit (client)	49.16 kB	+0.06%	+27 B 🔺
@sentry/core/server	65.47 kB	+0.04%	+22 B 🔺
@sentry/core/browser	51.87 kB	+0.06%	+29 B 🔺
@sentry/node	123.25 kB	+0.05%	+52 B 🔺
@sentry/node/import (ESM hook with diagnostics-channel injection)	85.23 kB	-	-
@sentry/node - without tracing	87.75 kB	+0.04%	+27 B 🔺
@sentry/node - without channel injection	102.92 kB	+0.06%	+59 B 🔺
@sentry/aws-serverless	95.95 kB	+0.08%	+68 B 🔺
@sentry/cloudflare (withSentry) - minified	200.65 kB	+0.08%	+143 B 🔺
@sentry/cloudflare (withSentry)	499.13 kB	+0.08%	+367 B 🔺

View base workflow run

[Lms24]

I think we can do something better here which is what we decided on last week but I didn't have time to implement yet: Let's just always flush at segment end (with the delay), regardless of environment.

In Python, we already made that change after noticing that the 5s flushing interval accumulates a lot of memory in high-throughput environments. Since we make one request per trace anyway, the number of requests shouldn't be drastically higher.

That is, as long as we can expect that traces are generally well-formed (i.e. child spans ending before their segment span). For malformed traces, with long-running child spans we would increase the request count. I think this is a fine tradeoff IMHO.

If you have (or anyone else has) concerns about this, I'd prefer keeping the two integrations separate because the merge increases bundle size for the browser version. Which was the reason why I opted against combining them initially.

[mydea]

I think we can do something better here which is what we decided on last week but I didn't have time to implement yet: Let's just always flush at segment end (with the delay), regardless of environment.

In Python, we already made that change after noticing that the 5s flushing interval accumulates a lot of memory in high-throughput environments. Since we make one request per trace anyway, the number of requests shouldn't be drastically higher.

That is, as long as we can expect that traces are generally well-formed (i.e. child spans ending before their segment span). For malformed traces, with long-running child spans we would increase the request count. I think this is a fine tradeoff IMHO.

If you have (or anyone else has) concerns about this, I'd prefer keeping the two integrations separate because the merge increases bundle size for the browser version. Which was the reason why I opted against combining them initially.

sounds good to me, so I'll just change this so that the default for flushing is true I'd say, so you can still opt out?

[Lms24]

Thanks for reworking this!

Small positive side-effect for our tests: Span streaming tests should now run faster, given we flush way more quickly.

[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 5f6ffb5. Configure here.}

[cursor]

Types drop public integration export

Medium Severity

Removing the explicit spanStreamingIntegration re-export from framework index.types.ts files drops it from the public type surface. TypeScript export * from both client and server omits colliding names, so consumers of packages such as @sentry/astro and @sentry/nextjs can no longer import it. This is flagged because the review rules treat removal of a publicly exported function without a deprecation notice as a breaking change. The same explicit re-export is still required for other shared core symbols such as withStaticSpan.

Additional Locations (2)

• packages/nextjs/src/index.types.ts#L22-L36
• packages/nuxt/src/index.types.ts#L15-L24

^{Triggered by project rule: PR Review Guidelines for Cursor Bot}

^{Reviewed by Cursor Bugbot for commit 5f6ffb5. Configure here.}

[mydea]

this is fine

[mydea]

The browser (browserSpanStreaming.ts) and server (spanStreaming.ts) span streaming integrations were near-identical: the afterSpanEnd buffering was byte-for-byte the same, and they only differed in the eager-flush trigger. This collapses them into a single core integration, and makes flushing a trace shortly after its segment span ends the default for all runtimes, browser and server alike.

Both install sites now call spanStreamingIntegration() with no arguments: browserSpanApi._INTERNAL_ensureBrowserSpanStreaming and ServerRuntimeClient share one behavior. A trace is flushed:

• eagerly on flushTraceSpans (the Cloudflare drain),
• 500ms after its segment span ends, and
• otherwise on the SpanBuffer's own timeout/size thresholds.

Why default segment-end flushing on for the server too

Previously the server relied solely on the buffer thresholds and only the browser flushed on segment end, to avoid the server emitting more, smaller envelopes and to keep the browser's 500ms timer from holding the Node event loop open. The event-loop concern is already handled by safeUnref on the timer (a no-op in the browser), so there's no longer a reason to gate the segment-end path by runtime — flushing traces timely once their segment ends is the behavior we want everywhere.

The flushOnSegmentEnd option is retained (now defaulting to true) so a runtime can still opt out and fall back to threshold-only flushing.

Why keep it in core rather than moving to browser-utils/server-utils

The integrations are consumed internally by core — ServerRuntimeClient auto-adds it, and browserSpanApi/idleSpan auto-install it (a deliberate tree-shaking indirection). Since browser-utils and server-utils both depend on @sentry/core, core cannot import back from them without a circular dependency. Collapsing in-core sidesteps that entirely.

Export change

The integration now lives in shared-exports as a single shared symbol (star-exported by all entries) instead of being duplicated in browser-exports and server-exports. Previously the two entries resolved to different symbols, making the name an ambiguous star export that index.ts disambiguated with an explicit re-export. Now that both resolve to the same symbol, that explicit line collided with the star exports (leaving the root namespace undefined) and is removed. The startSpan/startInactiveSpan/startSpanManual disambiguation stays, as those remain genuinely distinct browser/server variants.

[github-actions]

size-limit report 📦

Path	Size	% Change	Change
@sentry/browser	28.56 kB	-	-
@sentry/browser - with treeshaking flags	26.92 kB	-	-
@sentry/browser - with treeshaking flags tracing without tracing	26.82 kB	-	-
@sentry/browser (incl. Tracing)	48.72 kB	+0.09%	+40 B 🔺
@sentry/browser (incl. Tracing + Span Streaming)	48.74 kB	+0.08%	+36 B 🔺
@sentry/browser (incl. Tracing, Profiling)	51.66 kB	+0.08%	+37 B 🔺
@sentry/browser (incl. Tracing, Replay)	88.19 kB	+0.05%	+38 B 🔺
@sentry/browser (incl. Tracing, Replay) - with treeshaking flags	77.6 kB	+0.06%	+39 B 🔺
@sentry/browser (incl. Tracing, Replay with Canvas)	92.88 kB	+0.04%	+35 B 🔺
@sentry/browser (incl. Tracing, Replay, Feedback)	105.83 kB	+0.04%	+39 B 🔺
@sentry/browser (incl. Feedback)	46.05 kB	-	-
@sentry/browser (incl. sendFeedback)	33.62 kB	-	-
@sentry/browser (incl. FeedbackAsync)	38.73 kB	-	-
@sentry/browser (incl. Metrics)	29.51 kB	-	-
@sentry/browser (incl. Logs)	29.8 kB	-	-
@sentry/browser (incl. Metrics & Logs)	30.43 kB	-	-
@sentry/react	30.3 kB	-	-
@sentry/react (incl. Tracing)	50.93 kB	+0.07%	+32 B 🔺
@sentry/vue	35.73 kB	+0.11%	+39 B 🔺
@sentry/vue (incl. Tracing)	50.97 kB	+0.08%	+38 B 🔺
@sentry/svelte	28.59 kB	-	-
CDN Bundle	30.35 kB	-	-
CDN Bundle (incl. Tracing)	49.32 kB	+0.06%	+25 B 🔺
CDN Bundle (incl. Logs, Metrics)	32.58 kB	-	-
CDN Bundle (incl. Tracing, Logs, Metrics)	51.21 kB	+0.06%	+26 B 🔺
CDN Bundle (incl. Replay, Logs, Metrics)	73.17 kB	-	-
CDN Bundle (incl. Tracing, Replay)	86.82 kB	+0.04%	+27 B 🔺
CDN Bundle (incl. Tracing, Replay, Logs, Metrics)	88.69 kB	+0.03%	+26 B 🔺
CDN Bundle (incl. Tracing, Replay, Feedback)	92.74 kB	+0.03%	+27 B 🔺
CDN Bundle (incl. Tracing, Replay, Feedback, Logs, Metrics)	94.61 kB	+0.03%	+25 B 🔺
CDN Bundle - uncompressed	89.95 kB	-	-
CDN Bundle (incl. Tracing) - uncompressed	147.05 kB	+0.07%	+89 B 🔺
CDN Bundle (incl. Logs, Metrics) - uncompressed	96.24 kB	-	-
CDN Bundle (incl. Tracing, Logs, Metrics) - uncompressed	152.74 kB	+0.06%	+89 B 🔺
CDN Bundle (incl. Replay, Logs, Metrics) - uncompressed	225.41 kB	-	-
CDN Bundle (incl. Tracing, Replay) - uncompressed	266.55 kB	+0.04%	+89 B 🔺
CDN Bundle (incl. Tracing, Replay, Logs, Metrics) - uncompressed	272.22 kB	+0.04%	+89 B 🔺
CDN Bundle (incl. Tracing, Replay, Feedback) - uncompressed	280.25 kB	+0.04%	+89 B 🔺
CDN Bundle (incl. Tracing, Replay, Feedback, Logs, Metrics) - uncompressed	285.92 kB	+0.04%	+89 B 🔺
@sentry/nextjs (client)	53.5 kB	+0.06%	+28 B 🔺
@sentry/sveltekit (client)	49.16 kB	+0.06%	+27 B 🔺
@sentry/core/server	65.47 kB	+0.04%	+22 B 🔺
@sentry/core/browser	51.87 kB	+0.06%	+29 B 🔺
@sentry/node	123.25 kB	+0.05%	+52 B 🔺
@sentry/node/import (ESM hook with diagnostics-channel injection)	85.23 kB	-	-
@sentry/node - without tracing	87.75 kB	+0.04%	+27 B 🔺
@sentry/node - without channel injection	102.92 kB	+0.06%	+59 B 🔺
@sentry/aws-serverless	95.95 kB	+0.08%	+68 B 🔺
@sentry/cloudflare (withSentry) - minified	200.65 kB	+0.08%	+143 B 🔺
@sentry/cloudflare (withSentry)	499.13 kB	+0.08%	+367 B 🔺

View base workflow run

[Lms24]

I think we can do something better here which is what we decided on last week but I didn't have time to implement yet: Let's just always flush at segment end (with the delay), regardless of environment.

In Python, we already made that change after noticing that the 5s flushing interval accumulates a lot of memory in high-throughput environments. Since we make one request per trace anyway, the number of requests shouldn't be drastically higher.

That is, as long as we can expect that traces are generally well-formed (i.e. child spans ending before their segment span). For malformed traces, with long-running child spans we would increase the request count. I think this is a fine tradeoff IMHO.

If you have (or anyone else has) concerns about this, I'd prefer keeping the two integrations separate because the merge increases bundle size for the browser version. Which was the reason why I opted against combining them initially.

[mydea]

I think we can do something better here which is what we decided on last week but I didn't have time to implement yet: Let's just always flush at segment end (with the delay), regardless of environment.

In Python, we already made that change after noticing that the 5s flushing interval accumulates a lot of memory in high-throughput environments. Since we make one request per trace anyway, the number of requests shouldn't be drastically higher.

That is, as long as we can expect that traces are generally well-formed (i.e. child spans ending before their segment span). For malformed traces, with long-running child spans we would increase the request count. I think this is a fine tradeoff IMHO.

If you have (or anyone else has) concerns about this, I'd prefer keeping the two integrations separate because the merge increases bundle size for the browser version. Which was the reason why I opted against combining them initially.

sounds good to me, so I'll just change this so that the default for flushing is true I'd say, so you can still opt out?

[Lms24]

Thanks for reworking this!

Small positive side-effect for our tests: Span streaming tests should now run faster, given we flush way more quickly.

[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 5f6ffb5. Configure here.}

[cursor]

Types drop public integration export

Medium Severity

Removing the explicit spanStreamingIntegration re-export from framework index.types.ts files drops it from the public type surface. TypeScript export * from both client and server omits colliding names, so consumers of packages such as @sentry/astro and @sentry/nextjs can no longer import it. This is flagged because the review rules treat removal of a publicly exported function without a deprecation notice as a breaking change. The same explicit re-export is still required for other shared core symbols such as withStaticSpan.

Additional Locations (2)

• packages/nextjs/src/index.types.ts#L22-L36
• packages/nuxt/src/index.types.ts#L15-L24

^{Triggered by project rule: PR Review Guidelines for Cursor Bot}

^{Reviewed by Cursor Bugbot for commit 5f6ffb5. Configure here.}

[mydea]

this is fine