Repository navigation
feat(tanstackstart-react): Serve the managed tunnel from the server entry - #25408
Conversation
size-limit report 📦Compared: 287ad6a (PR test merge using develop at f9f8adc) Against: ca4fc32 (develop) · base run #62950
|
2202cda to
46e486c
Compare
9069686 to
b589186
Compare
a5fcc1b to
f2a6beb
Compare
722f4c6 to
eec9ddf
Compare
|
bugbot run |
eec9ddf to
8d3dee9
Compare
|
bugbot run |
1 similar comment
|
bugbot run |
8d3dee9 to
8c6c1fa
Compare
6b24a7b to
64c909f
Compare
|
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. |
Optional E2E testsSome optional checks were not successful. They do not block the merge. 7 not successful, 58 successful. See the run.
Successful checks
|
isaacs
left a comment
There was a problem hiding this comment.
Some modest suggestions, but this overall is good. Replacing build-time route injection with a runtime matcher in front of the server entry is a nice improvement. Several of the comments below can be addressed by updating the PR description and changelog entry.
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 32e2e21. Configure here.
…ntry
The Vite plugin now wraps the app's server entry, so `Sentry.init({ tunnel: true })`
works with no build option and tunnel requests are answered before Start's
request middleware and routing. Every `tunnelRoute` form is served the same way:
`true` uses the DSN-derived path instead of a random one per build, and a static
path no longer patches the generated route tree.
…th Start routes on
…nel's server entry wrapper
…lides with an app route, as on develop
…and serve it from there
…ith setManagedTunnelDefaults
…equests The tunnel handler now answers a request without one with a 411.
…ants, which other variants already cover
…the client tests that repeat core's
…lRoute`, and use a static `tunnelRoute` as written
…the default server entry The default entry lives in `@tanstack/react-start`, which does not depend on the SDK, so the bare import failed when the SDK is not hoisted to where it can see it, like with pnpm's global virtual store or Yarn PnP.
…ping it for the tunnel
…c `tunnelRoute` with a 405 Without it, Start renders the app for them and runs its root loaders, which #24615 fixed for the route based tunnel.
…unnel path, the DSN-derived one included

TanStack Start picked a random tunnel path per build and patched the generated route tree to serve it.
Because the new approach relies less on build-time, the logic was changed to wrap the server entrypoint instead and only route the matching tunnel requests to our handler. The tradeoff is that every app using
sentryTanstackStart()gets its server entry wrapped, tunnel or not, sinceserveTunnelIntegration()turns the tunnel on at runtime. The original entry then loads through a?sentry-tunnel-originalid, and without a tunnel each request only pays one lookup.This isn't a breaking change, previously we injected a single endpoint handler, now we inject a middleware since the DSN is only known at runtime.
The base path comes from
router.basepath(or Vite'sbase), and thetunnel-basepathe2e variants cover it in both dev and prod.For reviewers: if you need an overview of what this is, refer to #25199.
closes #25461