Conversation
Contributor
size-limit report 📦
|
wrapServerLoadWithSentrywrapServerLoadWithSentry
3 tasks
kamilogorek
reviewed
Aug 11, 2023
kamilogorek
approved these changes
Aug 11, 2023
Co-authored-by: Kamil Ogórek <kamil.ogorek@gmail.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
As reported in #8610, our SvelteKit SDK caused server load data to be invalidated, resulting in said functions being called on every route change. I initially thought this was related to our Kit-specific client fetch instrumentation which turned out not to be causing this. Instead, the culprit is our
wrapServerLoadWithSentrywrapper:In the wrapper, we access
event.route.idto determine the route of the load function for the span description. Internally, SvelteKit puts a proxy on certaineventproperties, such asevent.route. In case any property ofevent.routewas accessed, SvelteKit marks this internally and send along a flag to the client. On a route change, the client would check this flag and mark the route as invalidated, thereby causing a call to the load function on each navigation.Took me quite a while to find the cause but thanks to @kamilogorek we found a fix to access the route id without invoking the proxy.
closes #8610