(nextJS) Strange stack traces without file extensions

[serglom21]

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

SDK Version

7.45.0

Framework Version

NextJS 12.2.2

Link to Sentry event

No response

SDK Setup

Sentry.init({
  enabled: true,
  // release: <process.env.sentryRelease>,
  // environment: <process.env.targetEnvironment>,
  // dsn: <process.env.dsn>,
  tracesSampleRate: 0.0001,
  sampleRate: 1,
  denyUrls: [
    /extensions\//i,
    /^chrome(-extensions?)?:\/\//i
  ],
  beforeSend: (event, _) => {
    const frames = (event.exception?.values || [])[0]?.stacktrace?.frames;
    if (
      frames?.every(
        (frame) =>
          !frame.filename ||
          frame.filename === "<anonymous>" ||
          frame.filename === "[native code]"
      )
    ) {
      return null;
    }
    return event;
  }
});

Steps to Reproduce

Repo shared by customer hosted here https://github.com/sergiosentry/sentry-nextjs

1. Run the repro and capture an error

NOTE: This setup was created without using the sentry wizard

Expected Result

I expect the Sentry event stack trace to have frames that point to the file where the error was thrown with the file extension

Like this one:

Actual Result

I get a weird looking stacktrace with the following path format which is not useful to me

This is some of the metadata captured with the event that might help understand where this is coming from

I am happy to share a link to a sample event internally since this is being opened on behalf of the customer and I would have to link the customer's instance.

┆Issue is synchronized with this Jira Improvement by Unito

[AbhiPrasad]

We chatted offline about this and the solution seems to be to make sure that the user changes to use the same setup generated by the Sentry Next.js wizard. That is they will:

1. wrap their next config with withSentryConfig
2. add sentry.server.config.js, sentry.edge.config.js, sentry.client.config.js as is instructed
3. use the sentry webpack plugin added by the nextjs sdk to upload sourcemaps.

[serglom21]

@AbhiPrasad Thanks!
Would using webpack to upload sourcemaps be a requirement to get this setup fully working?

Would the CLI just not work in this case?

[AbhiPrasad]

@sergiosentry if you wrap the config with withSentryConfig, the SDK will automatically inject a webpack plugin that will upload sourcemaps on when the nextjs app is built. Adding your own webpack plugin or using the CLI is not needed!

[bkrausz]

We are also seeing this stack trace weirdness, and are using the stock nextJS setup with withSentryConfig. Any pointer to where app:///PATHNAME gets translated so I can debug why this isn't happening for us?

[serglom21]

@AbhiPrasad Thanks! it seems that it still does not work even when wrapping the config with withSentryConfig. See here

[AbhiPrasad]

@sergiosentry in the example above, you've disabled the webpack plugin. This will prevent sourcemaps uploading from happening. See: https://docs.sentry.io/platforms/javascript/guides/nextjs/manual-setup/#disable-sentrywebpackplugin

sentry: {
  disableServerWebpackPlugin: true,
  disableClientWebpackPlugin: true,
},

[serglom21]

Based on the repro that was initially shared, I was able to reproduce a very similar issue (here) where the stack trace had a weird path (In my case, there might also been a problem with a missing source map but it is still weird that the SDK did not upload all mapping files automatically

).

My understanding is that the nextJS SDK calls the rewriteFrames integration under the hood to normalize some of the paths that nextJS stack traces produces by default (like app:///*). I tried debugging the specific part in the code that handles this (here) but it seems that at least for my use case, the rewriteFrames integration was not being called automatically. So after manually calling the integration on my sentry.client.config.js file (without providing any custom implementation as suggested in the docs), I was able to see a different stack trace without the weird frame titles:

integrations: [
    new RewriteFramesIntegration(),
]

working event

can anyone confirm that the rewriteFrames integration is not getting called automatically (as it should) and that manually calling it without any custom logic fixes this problem?

[lforst]

@serglom21 To upload the sourcemaps for the clientside that is not inside static/chunks/pages or static/chunks/app you need to set the widenClientFileUpload option to true inside next.config.js.

I know this is hella opaque and not well documented, however this option has a long history and we need it since historically uploading everything in static/chunks/** bumped the sourcemap upload times to upwards of 10+ minutes for some users.

As for the RewriteFrames integration: Do not set the integration manually (!!!!), it royally screws up your sourcemaps in 100% of the cases. The only reason the second event in your comment had working sourcemaps is that it was in dev mode and the sourcemaps resolving happens very differently in dev mode (source maps resolving is taken care of by Next.js dev server and not Sentry, this works without even uploading source maps).

[AbhiPrasad]

After some back and forths with the customer who reported the above issue, we were able to figure out most of the sourcemaps issues by getting them to use the nextjs sdk and upload sourcemaps via the sdk's built-in webpack plugin.

The only remaining issue was with TypeError: undefined is not an object (evaluating 'a.N') errors, which was reported in #9110.

It seems that these errors are being caused by google tag manager (gtm) scripts. It seems we can also identify that there is some google translate extensions/plugin that is the reason why it's happening. This affects everybody, including us. There is no way we will ever be able to provide meaningful stack traces for these errors.

My theory - google translate is injecting in a 2nd copy of google tag manager that is conflicting with the user's provided google tag manager, but cannot confirm without a repro.

For now I recommend ignoring this error as it's inactionable. This can be done by filtering out TypeError: undefined is not an object (evaluating 'a.N') errors. You can also make this check more robust by checking the stacktrace frames and only doing the filter if the filename does not have a file extension.