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.