Svelte Kit fetch requests are repeated again during client hydration

[janvotava]

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/sveltekit

SDK Version

7.52.1

Framework Version

1.5.0

Link to Sentry event

No response

SDK Setup

No response

Steps to Reproduce

1. Install default Sentry plugin with an auto instrumentation
2. Load page - fetch request are repeated although they have been loaded before on the server (SSR)

Expected Result

No request made on the client side.

Actual Result

There is duplicate requests after the client hydration.

[Lms24]

Hi @janvotava thanks for writing in!

Can you share a little more about what is happening, ideally a minimal reproduction where we can clearly see that the SDK is causing this?

Based on my understanding of SvelteKit's load functions (which I assume is where you're calling fetch), universal loads (+page.ts) are supposed to happen on both, client and server (?). Meaning initially, when the page is SSR'ed, a fetch will occur and then on the client side, why hydration is performed, another one happens.

We're patching SvelteKit's fetch function on the client-side to add tracing headers for distributed tracing between client and server but we're not actively making requests or interfering with hydration. At least knowingly 😅

[janvotava]

Hello @Lms24, thanks for a reply!

I have a sample app that fetches a endpoint with a random number.

On the client side with loads patched by Sentry

And with autoInstrument: false

Basically it skips reusing that <script type="application/json" data-sveltekit-fetched data-url="/api/random-number">{"status":200,"statusText":"","headers":{},"body":"0.07213929057627122"}</script> at the bottom of the page. Probably because of some Svelte Kit internal logic. Also can give you a sample PoC app (just tell me what to put into DSN).

Thanks a lot.

[Lms24]

Thanks for the additional information and clarification. Just to confirm, this request is made from a universal load function, right? I still need to reproduce it formally but I think, I already know what's going on and you're right with the script tags:

• during SSR, fetch is executed and the result is stored in a data-sveltekit-fetched script tag
• On the client, during hydration, SvelteKit's fetch functions try to obtain the data from the "cache" that's populated from the script tag(s) by matching the request.
  • For the request in question, there's no cache hit because we do in fact modify the fetch request by adding our sentry-trace and baggage headers to it. Headers influence the cache key and hence there's a cache miss :(
  • As a result, the data is actually fetched

So the question now is, how can we solve this? I see two potential solutions:

• Ideally, we wouldn't need to patch SvelteKit's fetch implementation at all. Instead, SvelteKit would expose a handleFetch hook on the client, just like it does on the server. This should give us a safe way of adding headers to the request. Although, caching can be a challenge in this scenario as well, depending on the order of the hook vs. the cache lookup. We already proposed this a while ago but haven't gotten much feedback form the Kit maintainers at this time.
• Less preferable but probably necessary until we have a better handleFetch hook: We do the cache lookup ourselves in the SDK client code and only add headers if there's a cache hit. It's probably not too hard to do but it's brittle, given that the cache selector creation could change at any time in Kit.

I'll need to think about this a bit more but feel free to suggest other options if you have an idea ;)

[Lms24]

I created a reproduction: https://github.com/Lms24/gh-js-8174

This shows the erroneous behavour by default and how disabeling autoInstrumentation solves it. I took some time with this repro so that ideally, SvelteKit maintainers can also look at it.

[Lms24]

One thing to add to this issue:

While it is clearly not intended that we cause this cache miss and we should do something about it (we will), the current behaviour of the SDK does not break applications. The reason is that universal load functions need to be built in a way that they can run on both, client and server.