Description
Is there an existing issue for this?
- I have checked for existing issues https://github.com/getsentry/sentry-javascript/issues
- I have reviewed the documentation https://docs.sentry.io/
- I am using the latest SDK release https://github.com/getsentry/sentry-javascript/releases
How do you use Sentry?
Sentry Saas (sentry.io)
Which SDK are you using?
@sentry/remix
SDK Version
7.83.0
Framework Version
No response
Link to Sentry event
No response
SDK Setup
No response
Steps to Reproduce
Follow the setup guide, trigger an SSR error that would expose ErrorBoundary.
Expected Result
The trace ID generated on the SSR request (which has the error + transaction) should be propagated to the client-side transaction.
Actual Result
Two separate root traces are generated, as the SSR trace ID is not propagated.
Cramer's Input That Doesnt Fit In This Template Monstrosity
In our instructions we have you wrapp App in withSentry. We do this to then inject into the loader. That works for successful page loads, but leaves you in a spot missing context in ErrorBoundary, which doesn't have access to loaders.
There are a number of issues with ErrorBoundary, so this might not solve it, but the general pattern I've found successful in express apps is to use AppLoaderContext defined within express itself. This ensures that all context is available, and I often reference it in the loader. It's possible theres a way (or we can get Remix to expose a way) to always guarantee broader context is available, as is already the case in loaders. That same context I believe is also available in the new meta functions, meaning we could probably avoid using the withSentry+loader+manual meta tags in general.