feat(bun): Add bunHttpServerIntegration

[mydea]

Adds a bunHttpIntegration to @sentry/bun that isolates incoming requests for servers built on node:http when running under the Bun runtime.

Problem

Bun does not emit the http.server.request.start diagnostics channel that the Node SDK relies on (getHttpServerSubscriptions in @sentry/core) to isolate each incoming request. As a result, servers built on node:http — notably Next.js running via bun --bun — do not get a fresh isolation scope and propagation context per request. Two unrelated incoming requests can therefore end up sharing a single trace_id.

This was surfaced by the nextjs-16-bun e2e app: propagation.test.ts › Does not propagate outgoing fetch requests not covered by tracePropagationTargets failed because the inbound and outbound transactions shared one trace.

Approach

bunHttpServerIntegration patches http.Server.prototype.emit and, on each server's first 'request' event, hands that server to the exact same core instrumentation the Node SDK uses (getHttpServerSubscriptions → instrumentServer). Core then installs its per-instance emit wrapper, which shadows the prototype patch for all subsequent requests to that server. No changes to @sentry/core, @sentry/opentelemetry, or the tracer — this only reuses existing core logic at a Bun-specific entry point.

Two decisions worth calling out:

• Prototype patch, not createServer. The server is typically created and listen()ed before Sentry initializes. Next.js in particular creates its http.Server and calls listen() before running the instrumentation.ts register() hook that loads the Sentry config, so a createServer patch installs too late to see the already-created server. Patching Server.prototype.emit catches pre-existing servers on their next request.
• spans option. When another layer already emits incoming-request spans (Next.js emits its own OpenTelemetry http.server spans), pass spans: false so the integration only isolates the request and resets its trace, without creating duplicate transactions. This mirrors how the Node httpIntegration uses disableIncomingRequestSpans.

The integration is a no-op outside Bun (guarded on process.versions.bun), and is added by default when using the bun sdk.

e2e wiring

The nextjs-16-bun test app uses @sentry/nextjs (→ @sentry/node), so it does not pick this up automatically. @sentry/bun is added as a dependency of that app and bunHttpIntegration({ spans: false }) is added to its server config.

Known limitation

Servers created via an ES module namespace import (import * as http from 'node:http') are covered, since we patch the shared http.Server class rather than a module binding.

[isaacs]

Only real concern that I saw is the missing errorMonitor symbol, and the other settings nits. (Posting as a comment rather than "request changes" because I'm going to be away next week and don't want to block landing once addressed.)

[isaacs]

It's interesting that Deno uses this same interface but sets sessions: false. I got confused at first and thought this was a bug, but actually it looks like Deno is the one that's wrong, and this is correct. Posted in #22888.

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

[cursor]

Wrong ignoreRequestBody request type

Medium Severity

ignoreRequestBody is typed to receive http.RequestOptions, but core invokes that callback with an incoming HttpIncomingMessage. Sibling options in the same interface already use HttpIncomingMessage, and Deno's equivalent integration types this correctly.

 

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

[mydea]

this is fine, we do the same in node