-
-
Notifications
You must be signed in to change notification settings - Fork 1.7k
fix(sveltekit): Handle server-only and shared load functions #7581
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
Conversation
if (isServerOnlyLoad(event)) { | ||
const sentryTraceHeader = event.request.headers.get('sentry-trace'); | ||
const baggageHeader = event.request.headers.get('baggage'); | ||
const traceparentData = sentryTraceHeader ? extractTraceparentData(sentryTraceHeader) : undefined; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
m: This conditional branching is a little confusing to me. Can we do it like the following?
Could we extract the request.headers
logic into a separate function that conditionally returns the traceparentData
and dynamicSamplingContext
?
We can then just reference those directly like trace
function used to.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done! Also removed the domain (will update the PR description for future refrerence)
size-limit report 📦
|
4bc2407
to
62dd95d
Compare
Previously, our server
wrapLoadWithSentry
assumed thatload
in+page.ts
and+page.server.ts
work identically. Unfortunately, the loadevent
arg has different contents for both, namely that the server-only load event contains arequest
object while the shared (client and server) load event doesn't. This PR fixes that by distinguishing between the two load types within the wrapper. Users can still use the same wrapper for both cases.Furthermore, this PR removes the usage of domains in the load wrapper, as on the server-side, we're already in a domain when
handleSentry
is used. Creating another domain here, caused the creation of a new transaction instead of adding the span to the transaction that was created byhandleSentry
.ref #7403