Repository navigation
feat(node,aws-serverless): Answer managed tunnel requests on Lambda - #26000
Conversation
size-limit report 📦Compared: 8719ead (PR test merge using develop at c6ad7e0) Against: 03492d2 (develop) · base run #65336
|
Optional E2E testsSome optional checks were not successful. They do not block the merge. 6 not successful, 51 successful. See the run.
Successful checks
|
a357b59 to
e260c45
Compare
e260c45 to
35c5803
Compare
35c5803 to
a2969c3
Compare
cbbbe3b to
335dfa3
Compare
335dfa3 to
126db26
Compare
126db26 to
7198f33
Compare
isaacs
left a comment
There was a problem hiding this comment.
Looks good, in line with the design of the rest of the stack. There's a few potential safety/footgun issues that could be hardened a bit.
Lambda runs no HTTP server, so `serveTunnelIntegration` redirects `_HANDLER` to a shim that answers tunnel events before the user's handler, when `init` runs from a preload. `wrapHandler` in `@sentry/aws-serverless` answers them too. The handler resolution moves to `@sentry/node`, and its loader stays out of the main entry.
… runtime Covers the aws-serverless and @sentry/node handler shims for async, callback and streaming handlers, the API Gateway, ALB and base64 event shapes, and a failed forward.
esbuild leaves `import.meta` empty when it bundles our ESM build to CJS, so `fileURLToPath` threw and `Sentry.init` crashed on Lambda. The shim is now resolved like `@sentry/aws-serverless` resolves its own, and a failure only turns the tunnel off.
…d without a tunnel
…ambda The Lambda tunnel copied every header of Sentry's answer, like `connection` and `transfer-encoding`, into its result, while the Node tunnel passes on only the ones the browser SDK reads.
The streaming tunnel only logged when reading Sentry's answer failed, so Lambda held the invocation until the function timeout. It now ends the stream with a 502.
With `Sentry.init` in the handler module, the runtime already loaded the handler, so tunnel requests reached the app without a word. The SDK now warns and points to a preload or `wrapHandler`.
5372683 to
2515607
Compare
A CJS bundle of `@sentry/node` also warns that it can't register its diagnostics-channel hooks, which has nothing to do with the tunnel.
A REST API's `path` leaves out the stage that an HTTP API's `rawPath` keeps, so no `basePath` worked for both on a named stage. The tunnel now matches the path the browser posted to, `requestContext.path`.
…rect the handler It's a misconfiguration message, so it goes through `consoleSandbox` instead of the debug logger and shows without `debug: true`.
…ches Which of `path` and `requestContext.path` holds the path the browser posted to depends on the domain, e.g. a custom domain with a base path mapping, so the tunnel no longer picks one.
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 357b058. Configure here.
…stage-stripped path matches
…s-serverless only The handler redirect, handler resolution and tunnel-only shim in @sentry/node shipped to every @sentry/node bundle, like Next.js server builds, for a Lambda setup we don't support. They go back to @sentry/aws-serverless, whose `wrapHandler` answers tunnel requests.
…ing `require` Webpack can't follow `require.resolve` passed around as a value and warns, so the shim is resolved with `createRequire` from `__filename` or `import.meta.url`.

Adds an AWS handler shim that handles tunnel events before they hit the user handler.
Note for reviewers: if you are lacking context on this PR, check #25997