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

[tiguchi]

Is there an existing issue for this?

• [X] I have checked for existing issues https://github.com/getsentry/sentry-javascript/issues
• [X] I have reviewed the documentation https://docs.sentry.io/
• [X] 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

[AbhiPrasad]

Hey, thanks for reporting. Could you try widening the module scope as per: https://docs.sentry.io/platforms/javascript/guides/nextjs/manual-setup/#widen-the-upload-scope? Does that fix your problem?

If that doesn't work, do you mind giving some details about your Next.js versions/Webpack versions, as well as a copy of your next.config.js?

[tiguchi]

Hi, thanks for your quick response!

I just tried the widenClientFileUpload: true setting and it doesn't appear to be working. The framework source map file is still missing.

Here's my next.config.js file:

// This file sets a custom webpack configuration to use your Next.js app with Sentry.
// https://nextjs.org/docs/api-reference/next.config.js/introduction
// https://docs.sentry.io/platforms/javascript/guides/nextjs/

const { withSentryConfig } = require("@sentry/nextjs");

const moduleExports = {
    // We use an alternative build directory when we build the app for deployment.
    // The BUILD_DIR environment variable is set up in the build script in package.json
    distDir: process.env.BUILD_DIR || ".next",
    eslint: {
        ignoreDuringBuilds: true
    },
    sentry: {
        widenClientFileUpload: true
    }
};

const sentryWebpackPluginOptions = {
    // For all available options, see: https://github.com/getsentry/sentry-webpack-plugin#options.
    validate: true,
    // The Sentry webpack plugin also automatically creates a Sentry release using the sentry-cli tool when dryRun is false
    dryRun: !process.env.BUILD_RELEASE
};

module.exports = withSentryConfig(moduleExports, sentryWebpackPluginOptions);

EDIT: Almost forgot to add the version info.

Here's the next info output:

    Operating System:
      Platform: linux
      Arch: x64
      Version: #58~20.04.1-Ubuntu SMP Tue Jun 14 11:29:12 UTC 2022
    Binaries:
      Node: 16.13.2
      npm: 8.10.0
      Yarn: 1.22.18
      pnpm: 7.3.0
    Relevant packages:
      next: 12.2.0
      eslint-config-next: N/A
      react: 18.1.0
      react-dom: 18.1.0

Webpack is a bit more difficult to track down, since it's not added as a direct dependency. I ran pnpm why webpack and here's the output for @sentry/nextjs:

@sentry/nextjs 7.3.0
└─┬ webpack 5.73.0 peer
  └─┬ terser-webpack-plugin 5.3.0
    └── webpack 5.73.0 peer

Different versions of webpack appear under Storbyook, but I don't think that's actually used during app build?

[varun-raj]

Looks like this was intentionally done, maybe will it work if we just override the ignore option?

https://github.com/getsentry/sentry-javascript/commit/670d8426a0ae16b645a5c1b5f336f4ae26f48d8d#diff-55396f0a8f12ba2eb7ce27f3cf886f946c29c2aa93b5d2f993dadbd5a9f3cc75R309

[github-actions[bot]]

This issue has gone three weeks without activity. In another week, I will close it.

But! If you comment or otherwise update it, I will reset the clock, and if you label it Status: Backlog or Status: In Progress, I will leave it alone ... forever!

---

"A weed is but an unloved flower." ― Ella Wheeler Wilcox 🥀

[tiguchi]

Here is a comment for the stale bot.

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

[michaelmerrill]

Any updates on this? I'm experiencing this issue using the Vercel integration with NextJS. I wasn't sure if the integration was broken or maybe I had misconfigured something as the Sentry console says "Source code was not found" for the error thrown in the NextJS walkthrough.

[daniellin215]

Bump on this issue, still happening for me to with widened upload scope.

[lforst]

Sup. We released a fix yesterday that will mark the unresolved stack frames as "irrelevant". Currently, we don't upload these "first load JS" files because they usually don't really contain any interesting code and it would just increase everyone's build times.

Unfortunately, we still have a bug in the product that even if all "important" frames could be resolved we still show a warning that there was a problem processing the event. I've raised this internally and we'll fix that.

If you really want to upload these files to get rid of the warning, you can set ignore: [] as @michaelschufi suggested.

[github-actions[bot]]

This issue has gone three weeks without activity. In another week, I will close it.

But! If you comment or otherwise update it, I will reset the clock, and if you label it Status: Backlog or Status: In Progress, I will leave it alone ... forever!

---

"A weed is but an unloved flower." ― Ella Wheeler Wilcox 🥀

[lforst]

This should be fixed in recent versions of the SDK. Feel free to ping us if this is not the case!