Repository navigation
Conversation
logaretm
added this pull request to stack #25201
October 15, 2026 20:01
Contributor
size-limit report 📦
|
![sentry-warden[bot]](https://avatars.githubusercontent.com/in/2755838?s=60&v=4){kind=small}
Member
Author
|
bugbot run |
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
logaretm
force-pushed
the
awad/tunnel-nextjs
branch
from
October 16, 2026 01:51
0bd8edd to
a0d5655
Compare
Member
Author
|
bugbot run |
logaretm
force-pushed
the
awad/tunnel-nextjs
branch
from
October 16, 2026 02:25
a0d5655 to
bff33ce
Compare
Member
Author
|
bugbot run |
logaretm
force-pushed
the
awad/tunnel-nextjs
branch
from
October 16, 2026 03:32
bff33ce to
61392db
Compare
Member
Author
|
bugbot run |
logaretm
force-pushed
the
awad/tunnel-nextjs
branch
from
October 16, 2026 04:23
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.
logaretm
force-pushed
the
awad/tunnel-nextjs
branch
from
October 16, 2026 04:48
ae51678 to
9c50125
Compare
logaretm
force-pushed
the
awad/tunnel-nextjs
branch
from
October 16, 2026 14:00
9c50125 to
e94f25d
Compare
logaretm
force-pushed
the
awad/tunnel-nextjs
branch
from
October 16, 2026 14:37
e94f25d to
efc9b07
Compare
logaretm
force-pushed
the
awad/tunnel-nextjs
branch
from
October 16, 2026 16:15
efc9b07 to
2e8e2b3
Compare
logaretm
force-pushed
the
awad/tunnel-nextjs
branch
from
October 16, 2026 17:56
2e8e2b3 to
2c6c3d8
Compare
…that differs from the server's
logaretm
force-pushed
the
awad/tunnel-nextjs
branch
from
October 19, 2026 04:58
b98ec0a to
5bc562c
Compare
logaretm
added a commit
that referenced
this pull request
Oct 23, 2026
…om the DSN (#25199) ### Overview SDK Tunnel is a feature that allows client SDKs (e.g: browser) to send their requests through an endpoint that lives on the user's own application that forwards to Sentry. This bypasses adblockers and similar extensions. Tunnels could be configured as a fixed endpoint defined by the user (defaulted to `/monitoring`) but that usually ends up in global adblocker lists. Alternatively, users can tell the SDK to use a random endpoint to bypass that. Previously the tunnel logic mostly lived in client bundles and in server frameworks build time, this had two issues: - Both client and server bundles needed to share a single ENV during build, or a single process. So both can agree on the random URL generated. - CI/CD workflows means assets can drift, so older client bundles might be sending requests to older server bundles and vice versa, what happens then is during the rollout/phase-out, the random endpoints won't match and thus these envelopes will be getting 404'ed. This stack of PRs re-works the idea by moving to more stable yet random URL generation based on the client's DSN and moves the tunnel handling into the runtime of the core SDK. Meaning tunneling now is a core SDK capability rather than a meta framework feature. Here is how it looks for users: ```ts // client, posts to a path hashed from the DSN, e.g. `/k3x9q2a` Sentry.init({ dsn, tunnel: true }); // server, nothing to do in a meta-framework, the SDK answers that path from its request hook. // You only need this if the browser uses a different DSN than the server. Sentry.init({ dsn, tunnel: { allowedDsns: [browserDsn] } }); ``` And a tunneled request goes like this: the framework hook calls `handleTunnelRequestIfMatched`, if the path matches it checks the envelope's DSN against the allowed ones and forwards it to Sentry, otherwise the request continues as normal. ### This PR This sets up the core for the new tunnel mechanism that the rest of the stack will be implemented against, it does the following: - Sets up the tunnel generation and matching logic. - Sets up global span/breadcrumb ignore rules for tunneled requests. - Adds request checking, header forwarding, and the proxying to the Sentry SaaS DSN. It also sets up a couple of key decisions that will carry over throughout the stack: - **Base paths are respected always:** if a user sets `/app` as a base path our tunnels handlers will expect that prefix. - **Servers always allow their own DSNs:** This avoids the footgun where a user misconfigures `allowedDSNs` on the server, this correction only applies if the client and server share the same DSN, if there is a different DSN involved then it is on the user to configure that correctly. Will work on documenting this. ### Reviewing the stack This PR and #25200 are where the actual behavior lives so these need the closest look, mainly `forwardEnvelope` and the base path handling in `tunnel.ts`. The framework PRs all follow the same pattern: find the earliest request hook the framework gives us, call the core handler there, and pass the framework's base path along. They are small, so ideally whoever knows that framework best picks it up: - TanStack Start #25408 - SvelteKit #25415 - Nuxt and Nitro #25418, this one has more going on since it has to run before the user's own server middleware - Astro #25419 - Remix #25420 - React Router #25422 - SolidStart #25423 #25414 is tests only, and Next.js #25424 is on hold, I will split it up before it's ready.
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.
tunnelRouterewrote envelopes straight to sentry.io, which leaked the user's cookies and only worked for SaaS DSNs, fixed by answering it from a generated app route on the DSN-derived path.The unit tests cover the rewrites, the injected options and the route file generation, and e2e variants check the App and Pages routers on Turbopack and webpack.
For reviewers: if you need an overview of what this is, refer to #25199.
closes #25466