Repository navigation
Conversation
logaretm
added this pull request to stack #25201
October 8, 2026 15:45
logaretm
force-pushed
the
awad/tunnel-core-dsn-path
branch
from
October 8, 2026 16:05
af27973 to
a2af1e1
Compare
logaretm
changed the title
logaretm
force-pushed
the
awad/tunnel-core-dsn-path
branch
4 times, most recently
from
October 15, 2026 15:36
c544ac0 to
89a5b2c
Compare
Contributor
size-limit report 📦
|
logaretm
force-pushed
the
awad/tunnel-core-dsn-path
branch
from
October 15, 2026 17:36
3bba67e to
4eea4c9
Compare
Member
Author
|
bugbot run |
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
Member
Author
|
bugbot run |
1 similar comment
Member
Author
|
bugbot run |
There was a problem hiding this comment.
✅ Bugbot reviewed your changes and found no new issues!
1 issue from previous review remains unresolved.
Comment @cursor review or bugbot run to trigger another review on this PR
Reviewed by Cursor Bugbot for commit a9a04bc. Configure here.
…om the DSN Browser and server SDKs can now derive the same opaque tunnel path from the DSN with `getTunnelPath`, so they agree on it without a build step. `isTunnelRequest` and `handleTunnelRequestIfMatched` let a server wrapper serve the tunnel when its client has `_managedTunnel` set, which `resolveServerTunnelOption` derives from the `tunnel` option. `allowedDsns` defaults to the client's DSN and the forward to Sentry runs with tracing suppressed.
…etTunnelPaths` Callers now hand `isTunnelRequest` a request-like object, so the matching rule can look at more of the request later without changing every framework. `getTunnelPaths` covers frameworks that can only register routes.
Servers derive the tunnel paths on every POST, so each DSN is now parsed and hashed once. An invalid DSN in `allowedDsns` also logs once instead of on every request.
…` on the server A relative `tunnel` can't be a transport URL on the server, so it now names the path the server serves, and `TunnelOptions.path` overrides the DSN-derived path. `tunnel: '/monitor'` on both sides then gives a fixed path the same way `tunnel: true` gives the DSN-derived one.
Server SDKs start the incoming request span before a framework hook gets to answer a tunnel request, so clients with the managed tunnel enabled now add the tunnel paths to `ignoreSpans`.
logaretm
force-pushed
the
awad/tunnel-core-dsn-path
branch
from
October 16, 2026 04:23
a9a04bc to
d53b981
Compare
This was referenced Oct 16, 2026
…ase path the same way
… base path after `init`
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
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
2 participants
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.
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 extentions.
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:
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.
This PR
This up the core for the new tunnel mechanism that will be implemented against, it does the following:
It also sets up a core key decisions that will carry over throughout the stack:
/appas a base path our tunnels handlers will expect that prefix.allowedDSNson 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.