Not all URLs are controllable by `sidecarUrl`
Environment
@spotlightjs/spotlight:2.4.1- A Next.js 14.2.7 app running over an ngrok tunnel
Steps to Reproduce
- Set up a Next.js app and reverse-proxy it through an ngrok tunnel for mobile development.
- Set up Spotlight as documented.
- Set up a Sidecar URL as follows:
- Update the
Spotlight.init({ sidecarUrl: "https://my-tunnel.ngrok.io/_sidecar/stream" }), using a prefix in the path, because/streamis needed for an app route. - In
next.config.js, set up a rewrite:{ source: "/_spotlight/stream", destination: "http://localhost:8969/stream" }
- Update the
- Launch the app and use the overlay within the page.
Expected Result
All calls needed for the overlay are done through sidecarUrl (like with tunnelRoute in Sentry SDK).
Actual Result
The overlay causes 404s calling https://my-tunnel.ngrok.io/clear (breaking the "clear events" button sync) and https://my-tunnel.ngrok.io/contextlines.
Triage
At least two locations in the code assume that the origin is the only custom part of the sidecarUrl:
packages/overlay/src/integrations/sentry/data/sentryDataCache.ts:49packages/overlay/src/App.tsx:140
My current workaround is to add /clear and /contextlines to the Next.js rewrites above. It'd be helpful if sidecarUrl acted as the base URL for all sidecar-related endpoints; however, this might require a breaking change in the config semantics.
P.S. Happy to contribute a patch if I can have some guidance on whether it's better to change the semantics of sidecarUrl or add another config variable.
Hey @freeatnet, thanks for the awesome report! We never expected sidecar to work with URL rewriting and under a path that is not the root. That said I see no good reason to keep it that way so I think your suggestion of only changing the final part of the URL for these other paths make sense.
Ideally the sidecarURL would not have had the /stream part but I don't really see a non-breaking way to change that and am not sure if it's worth the effort at this point.
So my proposal is, in those 2 places where we change the entire path portion of the URL, we take the path, rsplit it and only change the final bit. This should not change the current behavior while allowing your use case. Does that make sense?