Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

@sentry/remix fails to propagate trace headers on error boundaries #9737

Closed
3 tasks done
dcramer opened this issue Dec 4, 2023 · 0 comments · Fixed by #12110
Closed
3 tasks done

@sentry/remix fails to propagate trace headers on error boundaries #9737

dcramer opened this issue Dec 4, 2023 · 0 comments · Fixed by #12110
Assignees
Labels
Package: remix Issues related to the Sentry Remix SDK Type: Bug

Comments

@dcramer
Copy link
Member

dcramer commented Dec 4, 2023

Is there an existing issue for this?

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Package: remix Issues related to the Sentry Remix SDK Type: Bug
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants