Sourcemaps not working for Vercel + Sveltekit (paths for stack trace frames are absolute from the root filesystem rather than relative)

[fnimick]

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.92.0

Framework Version

Sveltekit 2.0.6

Link to Sentry event

https://million-marker.sentry.io/issues/4829645193/

SDK Setup

  Sentry.init({
    dsn: "https://[email protected]/4505744165699584",
    tracesSampleRate: 1,
    environment: PUBLIC_DEPLOY_ENV,
  });

Steps to Reproduce

At some point (not clear when), errors are being captured with the absolute path of the running file in the stack track frame (e.g. /var/task/vercel/path0/.svelte-kit/output/server/entries/endpoints/sentry-example/_server.js) rather than the expected relative stack track frame. This means that the sourcemaps are not matching, since the source map path being searched for is ~/var/task/vercel/path0/.svelte-kit/output/server/entries/endpoints/sentry-example/_server.js and the actual source map path from my uploaded artifact is ~/entries/endpoints/sentry-example/_server.js.

Expected Result

The stack trace should contain a relative frame which corresponds to generated source maps.

Actual Result

The stack trace frame is the full path, from the root /, of the running file in the Vercel VM.

[Lms24]

Hi @fnimick thanks for writing in! Can you show me your sentrySvelteKit config in you vite.config.js file?

Based on #8256, our Vite plugin should read the output directory during build and hand it to the server side SDK of Sentry. The SDK will rewrite the stack frame filenames, removing the absolute path before the output directory.

[fnimick]

@Lms24

    sentrySvelteKit({
      adapter: "vercel",
      autoUploadSourceMaps: process.env.PUBLIC_SENTRY_DISABLED !== "true",
      sourceMapsUploadOptions: {
        org: "million-marker",
        project: "future",
      },
      autoInstrument: false,
    }),
    sveltekit(), .....etc

This config hasn't changed since our first integration (which had no source map issues), so I doubt it's the source of the problem?

[Lms24]

I have a couple of concrete questions to debug this (alternatively, please feel free to provide a minimal reproducible example as a GH repo so we can debug it ourselves):

1. Can you set debug: true in sentrySvelteKit options and verify that there are no errors or warnings logged?
2. Can you confirm that there are logs from [Source Maps Plugin] during build?
3. Did you rename hooks.server.ts or move it to a location other than src/hooks.server.ts?
4. To verify that we correctly inject the discovered output directory into the server side code, please log the value of globalThis.__sentry_sveltekit_output_dir on the server side. I suggest logging it in beforeSend which should show us pretty well if the value is present at the time it's needed:

Sentry.init({
  dsn: 'DSN',
  // rest of your options
  beforeSend(event) {
    console.log(globalThis.__sentry_sveltekit_output_dir);
    return event;
  }
});

I have a feeling that this global value might not be set correctly but we need to verify this first.

[fnimick]

Source map logs are attached - looks like there are problems associating the files right away. (Unfortunately all the earlier logs are truncated due to vercel's 2000 line log storage limit).

source_map_logs.txt

The log for the globalThis.__sentry_sveltekit_output_dir is:
.svelte-kit/output .

[Lms24]

looks like there are problems associating the files right away

Hmm yeah good point. I'm not sure what's causing this though.

The log for the globalThis.__sentry_sveltekit_output_dir is:
.svelte-kit/output .

Thanks, this rules out my first suspicion. Can you confirm that you're building your projects artifacts into .svelte-kit/output?

It's very hard to debug this without a reproduction at hand. If you're not able to provide one, I can only suggest you to debug our custom rewriteFramesIteratee. This function is supposed to rewrite the absolute paths in the stacktrace to relative ones. Perhaps something is going wrong there.

Depending on the package manager, you'll find this function somewhere close to node_modules/@sentry/sveltekit/cjs/server/utils.js. Adding a couple of console logs should show us what's happening in there and how the stack frame is being processed.

[fnimick]

@Lms24 I think I solved part of it! I was accidentally initializing sentry twice in my server process, once I stopped doing that, the frames are being rewritten correctly.

However, I still have a problem with the sourcemaps. As an example, I have an error with a stack frame path of app:///entries/endpoints/sentry-example/_server.js - and sentry is looking for a file in release artifacts that matches ~/entries/endpoints/sentry-example/_server.js.

If I look at the release's artifacts, there is a file with that exact path - see bundle cf661877-3db8-5285-b3ce-ff10340913e2 for release 4dde5cc2c8eb136023edd4c7c732a4768935e19b - which has the files ~/entries/endpoints/sentry-example/_server.js . Yet this is not being matched?

[Lms24]

@fnimick just to sanity check, can you run npm why @sentry/vite-plugin and let me know which version of this package is installed?

[Lms24]

@fnimick apologies, I missed what was right in front of me: The uppermost stack frame in the errors associated with the linked release is already resolved and it should show you your sources content. You can see this because the file name already points to your source file, so it went through our source map symbolication process.

In fact, our source maps debugger (the component that opens when you click "Unminify Code") shouldn't be shown on the uppermost frame, as it is already resolved. That's a bug on our end and we're already aware of it. Sorry for the confusion!

The frames below the top frame still seem to be unresolved but they originate from SvelteKit source code, meaning that this is not relevant for the caught errors. For some reason the ~/index.js file seems to be empty which suggests that something else went wrong before or during upload. Not sure what we can do here but again, these frames are from the framework. Anyway, again sorry for the confusion!

[fnimick]

@Lms24 I think I have a potential answer for you. My main build is accidentally calling Sentry.init twice, when I remove a duplicate Sentry.init call, this problem goes away.

edit: removed question around "how to detect double initialization" - it's much easier to not do that in the first place.

[Lms24]

@fnimick Thanks for the reply - can we close this issue or is there anything still open from your end?

(apart from the known issue of the debugger pill showing up in the UI although the frame was symbolicated)

[fnimick]

Yes, this can be closed now - thank you! I'm working with Inngest to improve their docs on Sentry integration, which currently uses a Sentry.init that breaks sourcemap support.