Repository navigation
Conversation
size-limit report 📦Compared: 93d5729 (PR test merge using awad/runtime-tunnel-interception at 5845bd4) Against: 53daa00 (awad/runtime-tunnel-interception) · base run #64191
|
|
bugbot run |
0bd8edd to
a0d5655
Compare
|
bugbot run |
a0d5655 to
bff33ce
Compare
|
bugbot run |
bff33ce to
61392db
Compare
|
bugbot run |
5472088 to
ae51678
Compare
There was a problem hiding this comment.
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 5472088. Configure here.
| basePath: userNextConfig.basePath ?? '', | ||
| ...(path && { path }), | ||
| ...(allowedDsns && { allowedDsns }), | ||
| }; |
There was a problem hiding this comment.
Tunnel ignores Next.js trailingSlash
Medium Severity
getManagedTunnelOptions copies basePath from the Next.js config but not trailingSlash, so the browser posts to the slashless DSN path. With trailingSlash: true, Next.js 308s that POST before beforeFiles rewrites, and the DSN rewrite source also omits the optional trailing slash that the fixed-path rewrite includes. Unload-time keepalive fetches often will not follow that redirect, so events never reach the tunnel.
Additional Locations (1)
Reviewed by Cursor Bugbot for commit 5472088. Configure here.
ae51678 to
9c50125
Compare
9c50125 to
e94f25d
Compare
e94f25d to
efc9b07
Compare
efc9b07 to
2e8e2b3
Compare
2e8e2b3 to
2c6c3d8
Compare
5bc562c to
ef27f39
Compare
Optional E2E testsSome optional checks were not successful. They do not block the merge. 4 not successful, 50 successful. See the run.
Successful checks
|
Moves Cloudflare's `wrapRequestHandler` onto `wrapServerRequestHandler`, which `Deno.serve` and `Bun.serve` use since the previous PRs. Cloudflare keeps only what is unique to it: client init, the `cf` and cloud resource contexts, the protocol from `cf.httpProtocol`, the `isStreamingResponse` option, `captureErrors`, and the flush through `waitUntil`, which skips the dispose for a 101 response. The helpers that only the old code used (`captureIncomingRequestBody`, `shouldCreateIncomingRequestSpan`, `getIncomingRequestSpanHooks` and `addRequest`) are gone. `wrapRequestHandler` must run on workers without the `nodejs_compat` flag, such as Shopify Oxygen, and every `@sentry/server-utils` entry loads `node:async_hooks`. So the wrapper moves to a new entry, `@sentry/server-utils/request-handler`, with no Node.js imports. Deno and Bun import it from there too. Cloudflare's module graph test allows this one entry, and a new test in server-utils walks the entry's module graph and fails on any Node.js import. The wrapper gets three optional fields: `isStreamingResponse`, `onDone` (called once when the request is done, with the response if there is one), and a `mechanism` that can be left out to not capture errors. For streamed responses, the shared stream monitor replaces Cloudflare's `TransformStream`. Workers with a compatibility date before 2022-11-30 cannot construct a `ReadableStream` without the `streams_enable_constructors` flag, so the wrapper then ends at handler return, as the `TransformStream` fallback did. The monitor now locks the source body only in `start()`, so the original response stays usable in that case. The wrapper builds the new response from the original one, which keeps `encodeBody: 'manual'`. Visible changes for Cloudflare: - Request spans set `client.address` from `CF-Connecting-IP` (or another forwarding header), as on the other runtimes. This follows `dataCollection.userInfo`, which is `true` by default. - Request spans get the response header attributes, and events get the `response` context. - An error from the source of a streamed response is captured (unless `captureErrors` is `false`), and the span gets an error status. - If the user removed `httpServerIntegration`, request bodies follow `dataCollection.httpBodies`. Before, the SDK attached no body. The minified `withSentry` bundle grows by about 2.4 KB (212,385 to 214,853 bytes), under the 211 KiB limit. Most of it is the request session and client address code, which Cloudflare now shares. Fixes #25577 Fixes JS-3975 Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
…ncLocalStorage Without `AsyncLocalStorage` (for example on Shopify Oxygen, or on Workers without `nodejs_compat`), the SDK uses the stack fallback, and `withInvocationIsolationScope` does not fork. The scope it passes to its callback is a clone that is not the current isolation scope. The shared request handler wrote the request data and body to that clone, so an event captured in the handler, which reads the current scope, had no request body. The `hydrogen-react-router-7` E2E test caught this. The handler now gets the current isolation scope. With `AsyncLocalStorage`, that is the same scope as before. Without it, the request data goes where the body went before the move to the shared handler, and events now also get the request URL and method. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
With `serveTunnelIntegration`, Node, Bun and Deno servers and Cloudflare Workers now answer tunnel requests before the app sees them, whatever framework runs on top. `intercept: false` opts out, for apps that serve the tunnel from their own code. The tunnel never throws into the runtime: before a request is claimed any failure hands it to the app, after that it ends in a 502. The forward to Sentry is aborted when the browser goes away, and the http server instrumentation skips tunnel requests.
The runtimes answer managed tunnel requests now, so the framework SDKs stop answering them in their own request hooks. They keep passing their base path, and TanStack Start's `tunnelRoute` still enables the tunnel.
The Node, Bun and Deno SDKs install their tunnel hooks in `init` rather than from `serveTunnelIntegration`, so a tunnel a framework SDK enables, like TanStack Start's `tunnelRoute`, is answered too. The hooks answer nothing unless the tunnel is on, so `serveTunnelIntegration` is core's again on every runtime.
Lambda runs no HTTP server, so `wrapHandler` answers tunnel requests from API Gateway, function URL and ALB events before the handler runs.
`sentryCloudflareNitroPlugin` passes the body Nitro already read, so the runtime can answer tunnel requests. On Nitro v3, which has no `localFetch`, it wraps `fetch` instead of throwing.
Pages builds get the same Worker entry wrap as Workers again, which answers managed tunnel requests. It was dropped in #19558 only to keep it out of the bundle.
Lambda runs no HTTP server, so when `init` runs from a preload with the tunnel on, it redirects `_HANDLER` to a shim that answers tunnel requests from HTTP events before the handler. `@sentry/aws-serverless` keeps its own shim, and the handler resolution and tunnel helpers move to `@sentry/node` so both share them.
A framework's server bundle can carry its own copy of `@sentry/core`, so the base path and `tunnelRoute` defaults it set never reached the runtime's copy that answers the tunnel.
Its dynamic `require` made webpack warn in Next.js builds. Only the handler shims need it.
Non-POST requests to the tunnel path now go through the app.
A tunnel request from a prerendered page on a cold server reached the app, because the server config only ran from SSR pages and the middleware. Builds now also import it from the server entry, and the server `init` keeps the first client, so a `--import` preload doesn't initialize twice.
Runs the same cases against Node, Cloudflare, Bun and Deno servers, checking the app keeps serving after each, the tunnel answers what it owns, and nothing is reported to the app's project.
`@sentry/node` doesn't answer the tunnel on Bun, and Bun drops pipelined requests behind an async one. `packages/bun` runs the same cases against Bun's servers.
…equest` The tunnel route handler now leaves DSN normalization, the allowlist and tracing suppression to core. As in every other SDK, `allowedDsns` adds to the server's own DSN, and the default `POST` accepts the DSNs `serveTunnelIntegration` allows.
…ePath` `tunnel: true` in the browser now sends to `<basePath>/<hash>`, like the SvelteKit and React Router SDKs do with their base paths. A `basePath` the user set and a `tunnel` URL stay as written.
…the server `withSentryConfig` now injects `basePath` into production server and edge builds, not only in dev, and the server, edge and Cloudflare inits pass it to `setManagedTunnelDefaults`. `serveTunnelIntegration` then matches `/<basePath>/<hash>`, like the browser sends.
|
One or more gzipped bundles increased by more than 500 bytes. If this increase is intentional, add the Accept Bundlesize Increase label to this PR to rerun and accept the check. |


The managed tunnel from 11.10 ignored the Next.js
basePath, fixed by servingtunnel: trueunder it in the browser and on the server, which #25917 answers before Next sees the request, and by moving the tunnel route onto core'shandleTunnelRequest.The e2e variants serve the tunnel under a base path with and without an edge middleware, and check the forwarded events and that no tunnel spans are sent.
closes #25466