@sentry/nextjs does not upload sourcemaps for "first load JS" files

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 package are you using?

@sentry/nextjs

SDK Version

7.3.0

Framework Version

7.3.0

Link to Sentry event

https://sentry.io/organizations/ravo-llc/issues/3385096554

Steps to Reproduce

The @sentry/nextjs integration seems to be skipping the upload of sourcemaps for NextJS JavaScript files that are categorized as “first load JS shared by all”, e.g.:

+ First Load JS shared by all              745 kB
  ├ chunks/framework-d36e54abd99436b9.js   45.1 kB
  ├ chunks/main-e4617a57cbc2ff7d.js        28.7 kB
  ├ chunks/pages/_app-ca156fce00b9bdf4.js  669 kB
  ├ chunks/webpack-14d0779d6a8c8953.js     2.33 kB

Therefore all error events that have the framework / main files in the stacktrace cannot be properly processed.

Reproduction Steps

• Create a production build that also uploads source maps to Sentry
• Trigger a frontend error event
• Error event shows with obfuscated lines for “framework.js” stacktrace on Sentry. Also the following error message shows up:

Expected Result

I checked, and source maps are generated for those “first load shared by all” JS files. I expect them to be uploaded to Sentry, too

Actual Result

Source maps for framework.js, app.js, main.js etc. are not uploaded

[michaelschufi]

I’m experiencing the same issue. But I don’t think it actually matters that much, in the end it’s just visually wrong. Let me explain.

Workaround

Before I explain, why I think it’s not a huge issue, the workaround, which solved the problem.

As @varun-raj suggested, setting the ignore option to an empty array works. I made those changes:

// NextConfig
sentry: {
  widenClientFileUpload: true,
},

// SentryWebpackPluginOptions
{
  ignore: [],
}

Explanation and Thoughts

When Sentry is processing the event, it tries to get the source maps from the release archive the error event is connected to. Since the change @varun-raj mentioned, the framework’s code does not get uploaded by default anymore. This means that Sentry can’t find all the files to completely resolve stack trace.

But: The user code is still uploaded, so everything that’s specific to your project, can still be resolved.

As you can see in the following screenshot: the topmost part looks clean, and it’s clear where the error occurred.

However, it’s definitely a step back from the clear and concise view we get if all the sources can be resolved:

I understand that it’s in everyone’s interest to reduce unnecessary uploading of source maps. But it’s annoying to scroll through all the unnecessary framework stack trace part to reach the Breadcrumbs section in the issue view.

Note

I want to mention one thing that confused me about all of this. It’s the following processing error I get.

This occurs if the source file cannot be found, Sentry tries to access it (but it’s inaccessible because it’s a private page). In my opinion, it makes you troubleshoot in the wrong direction. Being new to Sentry, it’s weird to get such an error if you’re just using defaults everywhere. I first thought my config was wrong, the security settings were wrong, etc. until I read up on how it actually works. It would help to have some exceptions or a note if the event came from the Next.js SDK.

[tiguchi]

Here is a comment for the stale bot.