Repository navigation
Conversation
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.
Contributor
size-limit report 📦Compared: 5845bd4 (PR test merge using develop at 0041bc6) Against: 0041bc6 (develop) · base run #64433 ✅ Baseline matches: this diff contains only this PR's changes.
|
Contributor
|
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. |
Contributor
Optional E2E testsSome optional checks were not successful. They do not block the merge. 2 not successful, 52 successful. See the run.
Successful checks
|
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.
This was referenced Oct 30, 2026
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Every framework needed its own middleware to serve the managed tunnel, which kept breaking on catch-all routes and ordering, fixed by answering tunnel requests in the Node, Bun, Deno, Cloudflare and Lambda runtimes and dropping the framework hooks.
This stacks on #25588 (its two commits are included until it merges).