fix(nextjs): universal random tunnel path support

[logaretm]

When using Next.js with Turbopack and the Sentry tunnel route feature (tunnelRoute: true), several issues prevented events from being sent properly:

1. Tunnel Route Consistency (Turbopack)

Problem: Random tunnel routes were generated separately for client and server builds in Turbopack.

Solution: Implemented processs-level caching in withSentryConfig.ts:

• Extract tunnel route resolution into resolveTunnelRoute() function
• Use process.env to store the random tunnel value across server/client builds.

2. Filter Tunnel Request Spans

Problem: Requests to the tunnel route (before rewrite) and to Sentry ingest URLs (after rewrite) were creating spans that polluted Sentry with internal instrumentation noise, spans were being created by the middleware and OTEL node.js fetch instrumentation.

Solution: Implemented server-side span filtering:

• Created dropMiddlewareTunnelRequests() utility to detect and drop tunnel-related spans
• Filter spans originating from Middleware.execute (Next.js middleware)
• Filter spans originating from auto.http.otel.node_fetch (Node.js fetch instrumentation)
• Check both local tunnel paths and Sentry ingest URLs (using isSentryRequestSpan from @sentry/opentelemetry)
• Mark matching spans with TRANSACTION_ATTR_SHOULD_DROP_TRANSACTION to prevent them from being sent
• I tried beforeSampling hook but it didn't work for some reason, so I stuck with the drop attribute.

---

The final issue was excluding the tunnel requests from the middleware/proxy, but there are many blockers for a solution:

1. The config must be statically analyzable, so we cannot expose withSentryMiddlewareConfig wrapper of any kind.
2. Warning the user doesn't help much because they can't do anything about it since the tunnel route is random.
3. Tested out writing a loader for turbopack/webpack to inject the tunnel into the matcher as an array but user existing matcher can match still.
4. Only way is to inject an exclusion match into the user existing matcher, if it is an array then we need to inject it into each single entry.

I may explore this further later with a loader for both webpack/turbopack, and figure out a reliable way to inject the negative matchers into the user expressions.

[linear]

JS-549 AdBlock Plus blocking requests to Sentry and monitoring tunnel

[github-actions]

size-limit report 📦

Path	Size	% Change	Change
@sentry/browser	24.7 kB	-	-
@sentry/browser - with treeshaking flags	23.2 kB	-	-
@sentry/browser (incl. Tracing)	41.43 kB	-	-
@sentry/browser (incl. Tracing, Profiling)	45.75 kB	-	-
@sentry/browser (incl. Tracing, Replay)	79.85 kB	-	-
@sentry/browser (incl. Tracing, Replay) - with treeshaking flags	69.57 kB	-	-
@sentry/browser (incl. Tracing, Replay with Canvas)	84.55 kB	-	-
@sentry/browser (incl. Tracing, Replay, Feedback)	96.77 kB	-	-
@sentry/browser (incl. Feedback)	41.38 kB	-	-
@sentry/browser (incl. sendFeedback)	29.39 kB	-	-
@sentry/browser (incl. FeedbackAsync)	34.33 kB	-	-
@sentry/react	26.41 kB	-	-
@sentry/react (incl. Tracing)	43.43 kB	-	-
@sentry/vue	29.15 kB	-	-
@sentry/vue (incl. Tracing)	43.23 kB	-	-
@sentry/svelte	24.72 kB	-	-
CDN Bundle	27.02 kB	-	-
CDN Bundle (incl. Tracing)	42.02 kB	-	-
CDN Bundle (incl. Tracing, Replay)	78.53 kB	-	-
CDN Bundle (incl. Tracing, Replay, Feedback)	84.02 kB	-	-
CDN Bundle - uncompressed	79.17 kB	-	-
CDN Bundle (incl. Tracing) - uncompressed	124.55 kB	-	-
CDN Bundle (incl. Tracing, Replay) - uncompressed	240.59 kB	-	-
CDN Bundle (incl. Tracing, Replay, Feedback) - uncompressed	253.35 kB	-	-
@sentry/nextjs (client)	45.84 kB	-	-
@sentry/sveltekit (client)	41.79 kB	-	-
@sentry/node-core	51.02 kB	-	-
@sentry/node	159.34 kB	-	-
@sentry/node - without tracing	92.88 kB	-0.03%	-19 B 🔽
@sentry/aws-serverless	106.64 kB	-	-

View base workflow run

[github-actions]

node-overhead report 🧳

Note: This is a synthetic benchmark with a minimal express app and does not necessarily reflect the real-world performance impact in an application.

Scenario	Requests/s	% of Baseline	Prev. Requests/s	Change %
GET Baseline	8,807	-	8,853	-1%
GET With Sentry	1,632	19%	1,777	-8%
GET With Sentry (error only)	6,056	69%	6,031	+0%
POST Baseline	1,191	-	1,207	-1%
POST With Sentry	594	50%	597	-1%
POST With Sentry (error only)	1,032	87%	1,060	-3%
MYSQL Baseline	3,190	-	3,301	-3%
MYSQL With Sentry	421	13%	490	-14%
MYSQL With Sentry (error only)	2,615	82%	2,724	-4%

View base workflow run

[cursor]

Bug: Edge runtime missing tunnel route transaction filter

The event processor on the edge runtime only filters transactions based on the TRANSACTION_ATTR_SHOULD_DROP_TRANSACTION attribute, but lacks the explicit tunnel route transaction name check present in the server-side event processor. This asymmetry creates a defensive gap: if span marking fails for any reason, server-side transactions are still filtered by name, but edge-side transactions would slip through. For consistency and robustness, the edge-side event processor should include the same explicit tunnel route check that filters POST requests to the tunnel path.

[chargome]

Nice find!

[logaretm]

When using Next.js with Turbopack and the Sentry tunnel route feature (tunnelRoute: true), several issues prevented events from being sent properly:

1. Tunnel Route Consistency (Turbopack)

Problem: Random tunnel routes were generated separately for client and server builds in Turbopack.

Solution: Implemented processs-level caching in withSentryConfig.ts:

• Extract tunnel route resolution into resolveTunnelRoute() function
• Use process.env to store the random tunnel value across server/client builds.

2. Filter Tunnel Request Spans

Problem: Requests to the tunnel route (before rewrite) and to Sentry ingest URLs (after rewrite) were creating spans that polluted Sentry with internal instrumentation noise, spans were being created by the middleware and OTEL node.js fetch instrumentation.

Solution: Implemented server-side span filtering:

• Created dropMiddlewareTunnelRequests() utility to detect and drop tunnel-related spans
• Filter spans originating from Middleware.execute (Next.js middleware)
• Filter spans originating from auto.http.otel.node_fetch (Node.js fetch instrumentation)
• Check both local tunnel paths and Sentry ingest URLs (using isSentryRequestSpan from @sentry/opentelemetry)
• Mark matching spans with TRANSACTION_ATTR_SHOULD_DROP_TRANSACTION to prevent them from being sent
• I tried beforeSampling hook but it didn't work for some reason, so I stuck with the drop attribute.

---

The final issue was excluding the tunnel requests from the middleware/proxy, but there are many blockers for a solution:

1. The config must be statically analyzable, so we cannot expose withSentryMiddlewareConfig wrapper of any kind.
2. Warning the user doesn't help much because they can't do anything about it since the tunnel route is random.
3. Tested out writing a loader for turbopack/webpack to inject the tunnel into the matcher as an array but user existing matcher can match still.
4. Only way is to inject an exclusion match into the user existing matcher, if it is an array then we need to inject it into each single entry.

I may explore this further later with a loader for both webpack/turbopack, and figure out a reliable way to inject the negative matchers into the user expressions.

[linear]

JS-549 AdBlock Plus blocking requests to Sentry and monitoring tunnel

[github-actions]

size-limit report 📦

Path	Size	% Change	Change
@sentry/browser	24.7 kB	-	-
@sentry/browser - with treeshaking flags	23.2 kB	-	-
@sentry/browser (incl. Tracing)	41.43 kB	-	-
@sentry/browser (incl. Tracing, Profiling)	45.75 kB	-	-
@sentry/browser (incl. Tracing, Replay)	79.85 kB	-	-
@sentry/browser (incl. Tracing, Replay) - with treeshaking flags	69.57 kB	-	-
@sentry/browser (incl. Tracing, Replay with Canvas)	84.55 kB	-	-
@sentry/browser (incl. Tracing, Replay, Feedback)	96.77 kB	-	-
@sentry/browser (incl. Feedback)	41.38 kB	-	-
@sentry/browser (incl. sendFeedback)	29.39 kB	-	-
@sentry/browser (incl. FeedbackAsync)	34.33 kB	-	-
@sentry/react	26.41 kB	-	-
@sentry/react (incl. Tracing)	43.43 kB	-	-
@sentry/vue	29.15 kB	-	-
@sentry/vue (incl. Tracing)	43.23 kB	-	-
@sentry/svelte	24.72 kB	-	-
CDN Bundle	27.02 kB	-	-
CDN Bundle (incl. Tracing)	42.02 kB	-	-
CDN Bundle (incl. Tracing, Replay)	78.53 kB	-	-
CDN Bundle (incl. Tracing, Replay, Feedback)	84.02 kB	-	-
CDN Bundle - uncompressed	79.17 kB	-	-
CDN Bundle (incl. Tracing) - uncompressed	124.55 kB	-	-
CDN Bundle (incl. Tracing, Replay) - uncompressed	240.59 kB	-	-
CDN Bundle (incl. Tracing, Replay, Feedback) - uncompressed	253.35 kB	-	-
@sentry/nextjs (client)	45.84 kB	-	-
@sentry/sveltekit (client)	41.79 kB	-	-
@sentry/node-core	51.02 kB	-	-
@sentry/node	159.34 kB	-	-
@sentry/node - without tracing	92.88 kB	-0.03%	-19 B 🔽
@sentry/aws-serverless	106.64 kB	-	-

View base workflow run

[github-actions]

node-overhead report 🧳

Note: This is a synthetic benchmark with a minimal express app and does not necessarily reflect the real-world performance impact in an application.

Scenario	Requests/s	% of Baseline	Prev. Requests/s	Change %
GET Baseline	8,807	-	8,853	-1%
GET With Sentry	1,632	19%	1,777	-8%
GET With Sentry (error only)	6,056	69%	6,031	+0%
POST Baseline	1,191	-	1,207	-1%
POST With Sentry	594	50%	597	-1%
POST With Sentry (error only)	1,032	87%	1,060	-3%
MYSQL Baseline	3,190	-	3,301	-3%
MYSQL With Sentry	421	13%	490	-14%
MYSQL With Sentry (error only)	2,615	82%	2,724	-4%

View base workflow run

[cursor]

Bug: Edge runtime missing tunnel route transaction filter

The event processor on the edge runtime only filters transactions based on the TRANSACTION_ATTR_SHOULD_DROP_TRANSACTION attribute, but lacks the explicit tunnel route transaction name check present in the server-side event processor. This asymmetry creates a defensive gap: if span marking fails for any reason, server-side transactions are still filtered by name, but edge-side transactions would slip through. For consistency and robustness, the edge-side event processor should include the same explicit tunnel route check that filters POST requests to the tunnel path.

[chargome]

Nice find!

[logaretm]

When using Next.js with Turbopack and the Sentry tunnel route feature (tunnelRoute: true), several issues prevented events from being sent properly:

1. Tunnel Route Consistency (Turbopack)

Problem: Random tunnel routes were generated separately for client and server builds in Turbopack.

Solution: Implemented processs-level caching in withSentryConfig.ts:

• Extract tunnel route resolution into resolveTunnelRoute() function
• Use process.env to store the random tunnel value across server/client builds.

2. Filter Tunnel Request Spans

Problem: Requests to the tunnel route (before rewrite) and to Sentry ingest URLs (after rewrite) were creating spans that polluted Sentry with internal instrumentation noise, spans were being created by the middleware and OTEL node.js fetch instrumentation.

Solution: Implemented server-side span filtering:

• Created dropMiddlewareTunnelRequests() utility to detect and drop tunnel-related spans
• Filter spans originating from Middleware.execute (Next.js middleware)
• Filter spans originating from auto.http.otel.node_fetch (Node.js fetch instrumentation)
• Check both local tunnel paths and Sentry ingest URLs (using isSentryRequestSpan from @sentry/opentelemetry)
• Mark matching spans with TRANSACTION_ATTR_SHOULD_DROP_TRANSACTION to prevent them from being sent
• I tried beforeSampling hook but it didn't work for some reason, so I stuck with the drop attribute.

---

The final issue was excluding the tunnel requests from the middleware/proxy, but there are many blockers for a solution:

1. The config must be statically analyzable, so we cannot expose withSentryMiddlewareConfig wrapper of any kind.
2. Warning the user doesn't help much because they can't do anything about it since the tunnel route is random.
3. Tested out writing a loader for turbopack/webpack to inject the tunnel into the matcher as an array but user existing matcher can match still.
4. Only way is to inject an exclusion match into the user existing matcher, if it is an array then we need to inject it into each single entry.

I may explore this further later with a loader for both webpack/turbopack, and figure out a reliable way to inject the negative matchers into the user expressions.

[linear]

JS-549 AdBlock Plus blocking requests to Sentry and monitoring tunnel

[github-actions]

size-limit report 📦

Path	Size	% Change	Change
@sentry/browser	24.7 kB	-	-
@sentry/browser - with treeshaking flags	23.2 kB	-	-
@sentry/browser (incl. Tracing)	41.43 kB	-	-
@sentry/browser (incl. Tracing, Profiling)	45.75 kB	-	-
@sentry/browser (incl. Tracing, Replay)	79.85 kB	-	-
@sentry/browser (incl. Tracing, Replay) - with treeshaking flags	69.57 kB	-	-
@sentry/browser (incl. Tracing, Replay with Canvas)	84.55 kB	-	-
@sentry/browser (incl. Tracing, Replay, Feedback)	96.77 kB	-	-
@sentry/browser (incl. Feedback)	41.38 kB	-	-
@sentry/browser (incl. sendFeedback)	29.39 kB	-	-
@sentry/browser (incl. FeedbackAsync)	34.33 kB	-	-
@sentry/react	26.41 kB	-	-
@sentry/react (incl. Tracing)	43.43 kB	-	-
@sentry/vue	29.15 kB	-	-
@sentry/vue (incl. Tracing)	43.23 kB	-	-
@sentry/svelte	24.72 kB	-	-
CDN Bundle	27.02 kB	-	-
CDN Bundle (incl. Tracing)	42.02 kB	-	-
CDN Bundle (incl. Tracing, Replay)	78.53 kB	-	-
CDN Bundle (incl. Tracing, Replay, Feedback)	84.02 kB	-	-
CDN Bundle - uncompressed	79.17 kB	-	-
CDN Bundle (incl. Tracing) - uncompressed	124.55 kB	-	-
CDN Bundle (incl. Tracing, Replay) - uncompressed	240.59 kB	-	-
CDN Bundle (incl. Tracing, Replay, Feedback) - uncompressed	253.35 kB	-	-
@sentry/nextjs (client)	45.84 kB	-	-
@sentry/sveltekit (client)	41.79 kB	-	-
@sentry/node-core	51.02 kB	-	-
@sentry/node	159.34 kB	-	-
@sentry/node - without tracing	92.88 kB	-0.03%	-19 B 🔽
@sentry/aws-serverless	106.64 kB	-	-

View base workflow run

[github-actions]

node-overhead report 🧳

Note: This is a synthetic benchmark with a minimal express app and does not necessarily reflect the real-world performance impact in an application.

Scenario	Requests/s	% of Baseline	Prev. Requests/s	Change %
GET Baseline	8,807	-	8,853	-1%
GET With Sentry	1,632	19%	1,777	-8%
GET With Sentry (error only)	6,056	69%	6,031	+0%
POST Baseline	1,191	-	1,207	-1%
POST With Sentry	594	50%	597	-1%
POST With Sentry (error only)	1,032	87%	1,060	-3%
MYSQL Baseline	3,190	-	3,301	-3%
MYSQL With Sentry	421	13%	490	-14%
MYSQL With Sentry (error only)	2,615	82%	2,724	-4%

View base workflow run

[cursor]

Bug: Edge runtime missing tunnel route transaction filter

The event processor on the edge runtime only filters transactions based on the TRANSACTION_ATTR_SHOULD_DROP_TRANSACTION attribute, but lacks the explicit tunnel route transaction name check present in the server-side event processor. This asymmetry creates a defensive gap: if span marking fails for any reason, server-side transactions are still filtered by name, but edge-side transactions would slip through. For consistency and robustness, the edge-side event processor should include the same explicit tunnel route check that filters POST requests to the tunnel path.

[chargome]

Nice find!

[logaretm]

When using Next.js with Turbopack and the Sentry tunnel route feature (tunnelRoute: true), several issues prevented events from being sent properly:

1. Tunnel Route Consistency (Turbopack)

Problem: Random tunnel routes were generated separately for client and server builds in Turbopack.

Solution: Implemented processs-level caching in withSentryConfig.ts:

• Extract tunnel route resolution into resolveTunnelRoute() function
• Use process.env to store the random tunnel value across server/client builds.

2. Filter Tunnel Request Spans

Problem: Requests to the tunnel route (before rewrite) and to Sentry ingest URLs (after rewrite) were creating spans that polluted Sentry with internal instrumentation noise, spans were being created by the middleware and OTEL node.js fetch instrumentation.

Solution: Implemented server-side span filtering:

• Created dropMiddlewareTunnelRequests() utility to detect and drop tunnel-related spans
• Filter spans originating from Middleware.execute (Next.js middleware)
• Filter spans originating from auto.http.otel.node_fetch (Node.js fetch instrumentation)
• Check both local tunnel paths and Sentry ingest URLs (using isSentryRequestSpan from @sentry/opentelemetry)
• Mark matching spans with TRANSACTION_ATTR_SHOULD_DROP_TRANSACTION to prevent them from being sent
• I tried beforeSampling hook but it didn't work for some reason, so I stuck with the drop attribute.

---

The final issue was excluding the tunnel requests from the middleware/proxy, but there are many blockers for a solution:

1. The config must be statically analyzable, so we cannot expose withSentryMiddlewareConfig wrapper of any kind.
2. Warning the user doesn't help much because they can't do anything about it since the tunnel route is random.
3. Tested out writing a loader for turbopack/webpack to inject the tunnel into the matcher as an array but user existing matcher can match still.
4. Only way is to inject an exclusion match into the user existing matcher, if it is an array then we need to inject it into each single entry.

I may explore this further later with a loader for both webpack/turbopack, and figure out a reliable way to inject the negative matchers into the user expressions.

[linear]

JS-549 AdBlock Plus blocking requests to Sentry and monitoring tunnel

[github-actions]

size-limit report 📦

Path	Size	% Change	Change
@sentry/browser	24.7 kB	-	-
@sentry/browser - with treeshaking flags	23.2 kB	-	-
@sentry/browser (incl. Tracing)	41.43 kB	-	-
@sentry/browser (incl. Tracing, Profiling)	45.75 kB	-	-
@sentry/browser (incl. Tracing, Replay)	79.85 kB	-	-
@sentry/browser (incl. Tracing, Replay) - with treeshaking flags	69.57 kB	-	-
@sentry/browser (incl. Tracing, Replay with Canvas)	84.55 kB	-	-
@sentry/browser (incl. Tracing, Replay, Feedback)	96.77 kB	-	-
@sentry/browser (incl. Feedback)	41.38 kB	-	-
@sentry/browser (incl. sendFeedback)	29.39 kB	-	-
@sentry/browser (incl. FeedbackAsync)	34.33 kB	-	-
@sentry/react	26.41 kB	-	-
@sentry/react (incl. Tracing)	43.43 kB	-	-
@sentry/vue	29.15 kB	-	-
@sentry/vue (incl. Tracing)	43.23 kB	-	-
@sentry/svelte	24.72 kB	-	-
CDN Bundle	27.02 kB	-	-
CDN Bundle (incl. Tracing)	42.02 kB	-	-
CDN Bundle (incl. Tracing, Replay)	78.53 kB	-	-
CDN Bundle (incl. Tracing, Replay, Feedback)	84.02 kB	-	-
CDN Bundle - uncompressed	79.17 kB	-	-
CDN Bundle (incl. Tracing) - uncompressed	124.55 kB	-	-
CDN Bundle (incl. Tracing, Replay) - uncompressed	240.59 kB	-	-
CDN Bundle (incl. Tracing, Replay, Feedback) - uncompressed	253.35 kB	-	-
@sentry/nextjs (client)	45.84 kB	-	-
@sentry/sveltekit (client)	41.79 kB	-	-
@sentry/node-core	51.02 kB	-	-
@sentry/node	159.34 kB	-	-
@sentry/node - without tracing	92.88 kB	-0.03%	-19 B 🔽
@sentry/aws-serverless	106.64 kB	-	-

View base workflow run

[github-actions]

node-overhead report 🧳

Note: This is a synthetic benchmark with a minimal express app and does not necessarily reflect the real-world performance impact in an application.

Scenario	Requests/s	% of Baseline	Prev. Requests/s	Change %
GET Baseline	8,807	-	8,853	-1%
GET With Sentry	1,632	19%	1,777	-8%
GET With Sentry (error only)	6,056	69%	6,031	+0%
POST Baseline	1,191	-	1,207	-1%
POST With Sentry	594	50%	597	-1%
POST With Sentry (error only)	1,032	87%	1,060	-3%
MYSQL Baseline	3,190	-	3,301	-3%
MYSQL With Sentry	421	13%	490	-14%
MYSQL With Sentry (error only)	2,615	82%	2,724	-4%

View base workflow run

[cursor]

Bug: Edge runtime missing tunnel route transaction filter

The event processor on the edge runtime only filters transactions based on the TRANSACTION_ATTR_SHOULD_DROP_TRANSACTION attribute, but lacks the explicit tunnel route transaction name check present in the server-side event processor. This asymmetry creates a defensive gap: if span marking fails for any reason, server-side transactions are still filtered by name, but edge-side transactions would slip through. For consistency and robustness, the edge-side event processor should include the same explicit tunnel route check that filters POST requests to the tunnel path.

[chargome]

Nice find!

[logaretm]

When using Next.js with Turbopack and the Sentry tunnel route feature (tunnelRoute: true), several issues prevented events from being sent properly:

1. Tunnel Route Consistency (Turbopack)

Problem: Random tunnel routes were generated separately for client and server builds in Turbopack.

Solution: Implemented processs-level caching in withSentryConfig.ts:

• Extract tunnel route resolution into resolveTunnelRoute() function
• Use process.env to store the random tunnel value across server/client builds.

2. Filter Tunnel Request Spans

Problem: Requests to the tunnel route (before rewrite) and to Sentry ingest URLs (after rewrite) were creating spans that polluted Sentry with internal instrumentation noise, spans were being created by the middleware and OTEL node.js fetch instrumentation.

Solution: Implemented server-side span filtering:

• Created dropMiddlewareTunnelRequests() utility to detect and drop tunnel-related spans
• Filter spans originating from Middleware.execute (Next.js middleware)
• Filter spans originating from auto.http.otel.node_fetch (Node.js fetch instrumentation)
• Check both local tunnel paths and Sentry ingest URLs (using isSentryRequestSpan from @sentry/opentelemetry)
• Mark matching spans with TRANSACTION_ATTR_SHOULD_DROP_TRANSACTION to prevent them from being sent
• I tried beforeSampling hook but it didn't work for some reason, so I stuck with the drop attribute.

---

The final issue was excluding the tunnel requests from the middleware/proxy, but there are many blockers for a solution:

1. The config must be statically analyzable, so we cannot expose withSentryMiddlewareConfig wrapper of any kind.
2. Warning the user doesn't help much because they can't do anything about it since the tunnel route is random.
3. Tested out writing a loader for turbopack/webpack to inject the tunnel into the matcher as an array but user existing matcher can match still.
4. Only way is to inject an exclusion match into the user existing matcher, if it is an array then we need to inject it into each single entry.

I may explore this further later with a loader for both webpack/turbopack, and figure out a reliable way to inject the negative matchers into the user expressions.

[linear]

JS-549 AdBlock Plus blocking requests to Sentry and monitoring tunnel

[github-actions]

size-limit report 📦

Path	Size	% Change	Change
@sentry/browser	24.7 kB	-	-
@sentry/browser - with treeshaking flags	23.2 kB	-	-
@sentry/browser (incl. Tracing)	41.43 kB	-	-
@sentry/browser (incl. Tracing, Profiling)	45.75 kB	-	-
@sentry/browser (incl. Tracing, Replay)	79.85 kB	-	-
@sentry/browser (incl. Tracing, Replay) - with treeshaking flags	69.57 kB	-	-
@sentry/browser (incl. Tracing, Replay with Canvas)	84.55 kB	-	-
@sentry/browser (incl. Tracing, Replay, Feedback)	96.77 kB	-	-
@sentry/browser (incl. Feedback)	41.38 kB	-	-
@sentry/browser (incl. sendFeedback)	29.39 kB	-	-
@sentry/browser (incl. FeedbackAsync)	34.33 kB	-	-
@sentry/react	26.41 kB	-	-
@sentry/react (incl. Tracing)	43.43 kB	-	-
@sentry/vue	29.15 kB	-	-
@sentry/vue (incl. Tracing)	43.23 kB	-	-
@sentry/svelte	24.72 kB	-	-
CDN Bundle	27.02 kB	-	-
CDN Bundle (incl. Tracing)	42.02 kB	-	-
CDN Bundle (incl. Tracing, Replay)	78.53 kB	-	-
CDN Bundle (incl. Tracing, Replay, Feedback)	84.02 kB	-	-
CDN Bundle - uncompressed	79.17 kB	-	-
CDN Bundle (incl. Tracing) - uncompressed	124.55 kB	-	-
CDN Bundle (incl. Tracing, Replay) - uncompressed	240.59 kB	-	-
CDN Bundle (incl. Tracing, Replay, Feedback) - uncompressed	253.35 kB	-	-
@sentry/nextjs (client)	45.84 kB	-	-
@sentry/sveltekit (client)	41.79 kB	-	-
@sentry/node-core	51.02 kB	-	-
@sentry/node	159.34 kB	-	-
@sentry/node - without tracing	92.88 kB	-0.03%	-19 B 🔽
@sentry/aws-serverless	106.64 kB	-	-

View base workflow run

[github-actions]

node-overhead report 🧳

Note: This is a synthetic benchmark with a minimal express app and does not necessarily reflect the real-world performance impact in an application.

Scenario	Requests/s	% of Baseline	Prev. Requests/s	Change %
GET Baseline	8,807	-	8,853	-1%
GET With Sentry	1,632	19%	1,777	-8%
GET With Sentry (error only)	6,056	69%	6,031	+0%
POST Baseline	1,191	-	1,207	-1%
POST With Sentry	594	50%	597	-1%
POST With Sentry (error only)	1,032	87%	1,060	-3%
MYSQL Baseline	3,190	-	3,301	-3%
MYSQL With Sentry	421	13%	490	-14%
MYSQL With Sentry (error only)	2,615	82%	2,724	-4%

View base workflow run

[cursor]

Bug: Edge runtime missing tunnel route transaction filter

The event processor on the edge runtime only filters transactions based on the TRANSACTION_ATTR_SHOULD_DROP_TRANSACTION attribute, but lacks the explicit tunnel route transaction name check present in the server-side event processor. This asymmetry creates a defensive gap: if span marking fails for any reason, server-side transactions are still filtered by name, but edge-side transactions would slip through. For consistency and robustness, the edge-side event processor should include the same explicit tunnel route check that filters POST requests to the tunnel path.

[chargome]

Nice find!

[logaretm]

When using Next.js with Turbopack and the Sentry tunnel route feature (tunnelRoute: true), several issues prevented events from being sent properly:

1. Tunnel Route Consistency (Turbopack)

Problem: Random tunnel routes were generated separately for client and server builds in Turbopack.

Solution: Implemented processs-level caching in withSentryConfig.ts:

• Extract tunnel route resolution into resolveTunnelRoute() function
• Use process.env to store the random tunnel value across server/client builds.

2. Filter Tunnel Request Spans

Problem: Requests to the tunnel route (before rewrite) and to Sentry ingest URLs (after rewrite) were creating spans that polluted Sentry with internal instrumentation noise, spans were being created by the middleware and OTEL node.js fetch instrumentation.

Solution: Implemented server-side span filtering:

• Created dropMiddlewareTunnelRequests() utility to detect and drop tunnel-related spans
• Filter spans originating from Middleware.execute (Next.js middleware)
• Filter spans originating from auto.http.otel.node_fetch (Node.js fetch instrumentation)
• Check both local tunnel paths and Sentry ingest URLs (using isSentryRequestSpan from @sentry/opentelemetry)
• Mark matching spans with TRANSACTION_ATTR_SHOULD_DROP_TRANSACTION to prevent them from being sent
• I tried beforeSampling hook but it didn't work for some reason, so I stuck with the drop attribute.

---

The final issue was excluding the tunnel requests from the middleware/proxy, but there are many blockers for a solution:

1. The config must be statically analyzable, so we cannot expose withSentryMiddlewareConfig wrapper of any kind.
2. Warning the user doesn't help much because they can't do anything about it since the tunnel route is random.
3. Tested out writing a loader for turbopack/webpack to inject the tunnel into the matcher as an array but user existing matcher can match still.
4. Only way is to inject an exclusion match into the user existing matcher, if it is an array then we need to inject it into each single entry.

I may explore this further later with a loader for both webpack/turbopack, and figure out a reliable way to inject the negative matchers into the user expressions.

[linear]

JS-549 AdBlock Plus blocking requests to Sentry and monitoring tunnel

[github-actions]

size-limit report 📦

Path	Size	% Change	Change
@sentry/browser	24.7 kB	-	-
@sentry/browser - with treeshaking flags	23.2 kB	-	-
@sentry/browser (incl. Tracing)	41.43 kB	-	-
@sentry/browser (incl. Tracing, Profiling)	45.75 kB	-	-
@sentry/browser (incl. Tracing, Replay)	79.85 kB	-	-
@sentry/browser (incl. Tracing, Replay) - with treeshaking flags	69.57 kB	-	-
@sentry/browser (incl. Tracing, Replay with Canvas)	84.55 kB	-	-
@sentry/browser (incl. Tracing, Replay, Feedback)	96.77 kB	-	-
@sentry/browser (incl. Feedback)	41.38 kB	-	-
@sentry/browser (incl. sendFeedback)	29.39 kB	-	-
@sentry/browser (incl. FeedbackAsync)	34.33 kB	-	-
@sentry/react	26.41 kB	-	-
@sentry/react (incl. Tracing)	43.43 kB	-	-
@sentry/vue	29.15 kB	-	-
@sentry/vue (incl. Tracing)	43.23 kB	-	-
@sentry/svelte	24.72 kB	-	-
CDN Bundle	27.02 kB	-	-
CDN Bundle (incl. Tracing)	42.02 kB	-	-
CDN Bundle (incl. Tracing, Replay)	78.53 kB	-	-
CDN Bundle (incl. Tracing, Replay, Feedback)	84.02 kB	-	-
CDN Bundle - uncompressed	79.17 kB	-	-
CDN Bundle (incl. Tracing) - uncompressed	124.55 kB	-	-
CDN Bundle (incl. Tracing, Replay) - uncompressed	240.59 kB	-	-
CDN Bundle (incl. Tracing, Replay, Feedback) - uncompressed	253.35 kB	-	-
@sentry/nextjs (client)	45.84 kB	-	-
@sentry/sveltekit (client)	41.79 kB	-	-
@sentry/node-core	51.02 kB	-	-
@sentry/node	159.34 kB	-	-
@sentry/node - without tracing	92.88 kB	-0.03%	-19 B 🔽
@sentry/aws-serverless	106.64 kB	-	-

View base workflow run

[github-actions]

node-overhead report 🧳

Note: This is a synthetic benchmark with a minimal express app and does not necessarily reflect the real-world performance impact in an application.

Scenario	Requests/s	% of Baseline	Prev. Requests/s	Change %
GET Baseline	8,807	-	8,853	-1%
GET With Sentry	1,632	19%	1,777	-8%
GET With Sentry (error only)	6,056	69%	6,031	+0%
POST Baseline	1,191	-	1,207	-1%
POST With Sentry	594	50%	597	-1%
POST With Sentry (error only)	1,032	87%	1,060	-3%
MYSQL Baseline	3,190	-	3,301	-3%
MYSQL With Sentry	421	13%	490	-14%
MYSQL With Sentry (error only)	2,615	82%	2,724	-4%

View base workflow run

[cursor]

Bug: Edge runtime missing tunnel route transaction filter

The event processor on the edge runtime only filters transactions based on the TRANSACTION_ATTR_SHOULD_DROP_TRANSACTION attribute, but lacks the explicit tunnel route transaction name check present in the server-side event processor. This asymmetry creates a defensive gap: if span marking fails for any reason, server-side transactions are still filtered by name, but edge-side transactions would slip through. For consistency and robustness, the edge-side event processor should include the same explicit tunnel route check that filters POST requests to the tunnel path.

[chargome]

Nice find!

[logaretm]

When using Next.js with Turbopack and the Sentry tunnel route feature (tunnelRoute: true), several issues prevented events from being sent properly:

1. Tunnel Route Consistency (Turbopack)

Problem: Random tunnel routes were generated separately for client and server builds in Turbopack.

Solution: Implemented processs-level caching in withSentryConfig.ts:

• Extract tunnel route resolution into resolveTunnelRoute() function
• Use process.env to store the random tunnel value across server/client builds.

2. Filter Tunnel Request Spans

Problem: Requests to the tunnel route (before rewrite) and to Sentry ingest URLs (after rewrite) were creating spans that polluted Sentry with internal instrumentation noise, spans were being created by the middleware and OTEL node.js fetch instrumentation.

Solution: Implemented server-side span filtering:

• Created dropMiddlewareTunnelRequests() utility to detect and drop tunnel-related spans
• Filter spans originating from Middleware.execute (Next.js middleware)
• Filter spans originating from auto.http.otel.node_fetch (Node.js fetch instrumentation)
• Check both local tunnel paths and Sentry ingest URLs (using isSentryRequestSpan from @sentry/opentelemetry)
• Mark matching spans with TRANSACTION_ATTR_SHOULD_DROP_TRANSACTION to prevent them from being sent
• I tried beforeSampling hook but it didn't work for some reason, so I stuck with the drop attribute.

---

The final issue was excluding the tunnel requests from the middleware/proxy, but there are many blockers for a solution:

1. The config must be statically analyzable, so we cannot expose withSentryMiddlewareConfig wrapper of any kind.
2. Warning the user doesn't help much because they can't do anything about it since the tunnel route is random.
3. Tested out writing a loader for turbopack/webpack to inject the tunnel into the matcher as an array but user existing matcher can match still.
4. Only way is to inject an exclusion match into the user existing matcher, if it is an array then we need to inject it into each single entry.

I may explore this further later with a loader for both webpack/turbopack, and figure out a reliable way to inject the negative matchers into the user expressions.

[linear]

JS-549 AdBlock Plus blocking requests to Sentry and monitoring tunnel

[github-actions]

size-limit report 📦

Path	Size	% Change	Change
@sentry/browser	24.7 kB	-	-
@sentry/browser - with treeshaking flags	23.2 kB	-	-
@sentry/browser (incl. Tracing)	41.43 kB	-	-
@sentry/browser (incl. Tracing, Profiling)	45.75 kB	-	-
@sentry/browser (incl. Tracing, Replay)	79.85 kB	-	-
@sentry/browser (incl. Tracing, Replay) - with treeshaking flags	69.57 kB	-	-
@sentry/browser (incl. Tracing, Replay with Canvas)	84.55 kB	-	-
@sentry/browser (incl. Tracing, Replay, Feedback)	96.77 kB	-	-
@sentry/browser (incl. Feedback)	41.38 kB	-	-
@sentry/browser (incl. sendFeedback)	29.39 kB	-	-
@sentry/browser (incl. FeedbackAsync)	34.33 kB	-	-
@sentry/react	26.41 kB	-	-
@sentry/react (incl. Tracing)	43.43 kB	-	-
@sentry/vue	29.15 kB	-	-
@sentry/vue (incl. Tracing)	43.23 kB	-	-
@sentry/svelte	24.72 kB	-	-
CDN Bundle	27.02 kB	-	-
CDN Bundle (incl. Tracing)	42.02 kB	-	-
CDN Bundle (incl. Tracing, Replay)	78.53 kB	-	-
CDN Bundle (incl. Tracing, Replay, Feedback)	84.02 kB	-	-
CDN Bundle - uncompressed	79.17 kB	-	-
CDN Bundle (incl. Tracing) - uncompressed	124.55 kB	-	-
CDN Bundle (incl. Tracing, Replay) - uncompressed	240.59 kB	-	-
CDN Bundle (incl. Tracing, Replay, Feedback) - uncompressed	253.35 kB	-	-
@sentry/nextjs (client)	45.84 kB	-	-
@sentry/sveltekit (client)	41.79 kB	-	-
@sentry/node-core	51.02 kB	-	-
@sentry/node	159.34 kB	-	-
@sentry/node - without tracing	92.88 kB	-0.03%	-19 B 🔽
@sentry/aws-serverless	106.64 kB	-	-

View base workflow run

[github-actions]

node-overhead report 🧳

Note: This is a synthetic benchmark with a minimal express app and does not necessarily reflect the real-world performance impact in an application.

Scenario	Requests/s	% of Baseline	Prev. Requests/s	Change %
GET Baseline	8,807	-	8,853	-1%
GET With Sentry	1,632	19%	1,777	-8%
GET With Sentry (error only)	6,056	69%	6,031	+0%
POST Baseline	1,191	-	1,207	-1%
POST With Sentry	594	50%	597	-1%
POST With Sentry (error only)	1,032	87%	1,060	-3%
MYSQL Baseline	3,190	-	3,301	-3%
MYSQL With Sentry	421	13%	490	-14%
MYSQL With Sentry (error only)	2,615	82%	2,724	-4%

View base workflow run

[cursor]

Bug: Edge runtime missing tunnel route transaction filter

The event processor on the edge runtime only filters transactions based on the TRANSACTION_ATTR_SHOULD_DROP_TRANSACTION attribute, but lacks the explicit tunnel route transaction name check present in the server-side event processor. This asymmetry creates a defensive gap: if span marking fails for any reason, server-side transactions are still filtered by name, but edge-side transactions would slip through. For consistency and robustness, the edge-side event processor should include the same explicit tunnel route check that filters POST requests to the tunnel path.

[chargome]

Nice find!

[logaretm]

When using Next.js with Turbopack and the Sentry tunnel route feature (tunnelRoute: true), several issues prevented events from being sent properly:

1. Tunnel Route Consistency (Turbopack)

Problem: Random tunnel routes were generated separately for client and server builds in Turbopack.

Solution: Implemented processs-level caching in withSentryConfig.ts:

• Extract tunnel route resolution into resolveTunnelRoute() function
• Use process.env to store the random tunnel value across server/client builds.

2. Filter Tunnel Request Spans

Problem: Requests to the tunnel route (before rewrite) and to Sentry ingest URLs (after rewrite) were creating spans that polluted Sentry with internal instrumentation noise, spans were being created by the middleware and OTEL node.js fetch instrumentation.

Solution: Implemented server-side span filtering:

• Created dropMiddlewareTunnelRequests() utility to detect and drop tunnel-related spans
• Filter spans originating from Middleware.execute (Next.js middleware)
• Filter spans originating from auto.http.otel.node_fetch (Node.js fetch instrumentation)
• Check both local tunnel paths and Sentry ingest URLs (using isSentryRequestSpan from @sentry/opentelemetry)
• Mark matching spans with TRANSACTION_ATTR_SHOULD_DROP_TRANSACTION to prevent them from being sent
• I tried beforeSampling hook but it didn't work for some reason, so I stuck with the drop attribute.

---

The final issue was excluding the tunnel requests from the middleware/proxy, but there are many blockers for a solution:

1. The config must be statically analyzable, so we cannot expose withSentryMiddlewareConfig wrapper of any kind.
2. Warning the user doesn't help much because they can't do anything about it since the tunnel route is random.
3. Tested out writing a loader for turbopack/webpack to inject the tunnel into the matcher as an array but user existing matcher can match still.
4. Only way is to inject an exclusion match into the user existing matcher, if it is an array then we need to inject it into each single entry.

I may explore this further later with a loader for both webpack/turbopack, and figure out a reliable way to inject the negative matchers into the user expressions.

[linear]

JS-549 AdBlock Plus blocking requests to Sentry and monitoring tunnel

[github-actions]

size-limit report 📦

Path	Size	% Change	Change
@sentry/browser	24.7 kB	-	-
@sentry/browser - with treeshaking flags	23.2 kB	-	-
@sentry/browser (incl. Tracing)	41.43 kB	-	-
@sentry/browser (incl. Tracing, Profiling)	45.75 kB	-	-
@sentry/browser (incl. Tracing, Replay)	79.85 kB	-	-
@sentry/browser (incl. Tracing, Replay) - with treeshaking flags	69.57 kB	-	-
@sentry/browser (incl. Tracing, Replay with Canvas)	84.55 kB	-	-
@sentry/browser (incl. Tracing, Replay, Feedback)	96.77 kB	-	-
@sentry/browser (incl. Feedback)	41.38 kB	-	-
@sentry/browser (incl. sendFeedback)	29.39 kB	-	-
@sentry/browser (incl. FeedbackAsync)	34.33 kB	-	-
@sentry/react	26.41 kB	-	-
@sentry/react (incl. Tracing)	43.43 kB	-	-
@sentry/vue	29.15 kB	-	-
@sentry/vue (incl. Tracing)	43.23 kB	-	-
@sentry/svelte	24.72 kB	-	-
CDN Bundle	27.02 kB	-	-
CDN Bundle (incl. Tracing)	42.02 kB	-	-
CDN Bundle (incl. Tracing, Replay)	78.53 kB	-	-
CDN Bundle (incl. Tracing, Replay, Feedback)	84.02 kB	-	-
CDN Bundle - uncompressed	79.17 kB	-	-
CDN Bundle (incl. Tracing) - uncompressed	124.55 kB	-	-
CDN Bundle (incl. Tracing, Replay) - uncompressed	240.59 kB	-	-
CDN Bundle (incl. Tracing, Replay, Feedback) - uncompressed	253.35 kB	-	-
@sentry/nextjs (client)	45.84 kB	-	-
@sentry/sveltekit (client)	41.79 kB	-	-
@sentry/node-core	51.02 kB	-	-
@sentry/node	159.34 kB	-	-
@sentry/node - without tracing	92.88 kB	-0.03%	-19 B 🔽
@sentry/aws-serverless	106.64 kB	-	-

View base workflow run

[github-actions]

node-overhead report 🧳

Note: This is a synthetic benchmark with a minimal express app and does not necessarily reflect the real-world performance impact in an application.

Scenario	Requests/s	% of Baseline	Prev. Requests/s	Change %
GET Baseline	8,807	-	8,853	-1%
GET With Sentry	1,632	19%	1,777	-8%
GET With Sentry (error only)	6,056	69%	6,031	+0%
POST Baseline	1,191	-	1,207	-1%
POST With Sentry	594	50%	597	-1%
POST With Sentry (error only)	1,032	87%	1,060	-3%
MYSQL Baseline	3,190	-	3,301	-3%
MYSQL With Sentry	421	13%	490	-14%
MYSQL With Sentry (error only)	2,615	82%	2,724	-4%

View base workflow run

[cursor]

Bug: Edge runtime missing tunnel route transaction filter

The event processor on the edge runtime only filters transactions based on the TRANSACTION_ATTR_SHOULD_DROP_TRANSACTION attribute, but lacks the explicit tunnel route transaction name check present in the server-side event processor. This asymmetry creates a defensive gap: if span marking fails for any reason, server-side transactions are still filtered by name, but edge-side transactions would slip through. For consistency and robustness, the edge-side event processor should include the same explicit tunnel route check that filters POST requests to the tunnel path.

[chargome]

Nice find!