Sentry sending the wrong release when capturing an exception

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

Framework Version

Next 12.2.5

Link to Sentry event

https://sentry.io/organizations/maven-com/issues/3576614941/events/c36e908b7bb1426b8fd78b96f8659d71/?environment=production&project=5632569&statsPeriod=14d

Steps to Reproduce

1. Deploy to Vercel, which is connected to Sentry
2. Verify that there is a release in Sentry with the commit SHA of what was just deployed
3. Go to deployed site
4. Trigger an error
5. See in Sentry what release that error logs

Expected Result

The release should be the newest commit SHA

Actual Result

The release is stuck on some old commit SHA. As you can see in the screenshot, we have a page that just shows the commit SHA of what’s deployed. We expect that SHA to be the same as the release in the network request but it’s not. In this particular case, we’ve deployed to production 4 times between release 8ff5 and 52ee meaning Sentry isn’t just stuck on the last release.

We’ve also verified that the 52ee release was indeed released on Sentry.

What I think is the error

I think Next.js’s build cache (webpack under-the-hood) is causing the error. When I redeploy in Vercel without using the cache, the Sentry release updates. I think my configs are setup correctly though:

sentry.client.config

// This file configures the initialization of Sentry on the browser.
// The config you add here will be used whenever a page is visited.
// https://docs.sentry.io/platforms/javascript/guides/nextjs/
import * as Sentry from '@sentry/nextjs';

const SENTRY_DSN = process.env.SENTRY_DSN || process.env.NEXT_PUBLIC_SENTRY_DSN;

Sentry.init({
  enabled: process.env.NODE_ENV === 'production',
  environment: process.env.NEXT_PUBLIC_ENV === 'PROD' ? 'production' : 'development',
  dsn: SENTRY_DSN,
  // Adjust this value in production, or use tracesSampler for greater control
  tracesSampleRate: 1.0,
  // ...
  // Note: if you want to override the automatic release value, do not set a
  // `release` value here - use the environment variable `SENTRY_RELEASE`, so
  // that it will also get attached to your source maps
});

next.config.js

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

const sentryWebpackPluginOptions = {
  // Additional config options for the Sentry Webpack plugin. Keep in mind that
  // the following options are set automatically, and overriding them is not
  // recommended:
  //   release, url, org, project, authToken, configFile, stripPrefix,
  //   urlPrefix, include, ignore

  // dryRun is true only when we are in the test or dev env
  dryRun: process.env.NODE_ENV === 'development' || (process.env.NEXT_PUBLIC_ENV ?? '').toLowerCase() === 'test',

  silent: true, // Suppresses all logs
  // For all available options, see:
  // https://github.com/getsentry/sentry-webpack-plugin#options.
};


const moduleExports = {
  sentry: {
    hideSourceMaps: true,
  },
  webpack: (config, { webpack }) => {
    config.plugins.push(
      new webpack.DefinePlugin({
        // Tree shake Sentry, taken from https://docs.sentry.io/platforms/javascript/configuration/tree-shaking/
        __SENTRY_DEBUG__: false,
        __SENTRY_TRACING__: false,
      }),
    );

    // return the modified config
    return config;
  },
  ...
}

module.exports = withSentryConfig(moduleExports, sentryWebpackPluginOptions);

This might be related to https://github.com/getsentry/sentry-javascript/issues/4373

[zacharyliu]

As a workaround for Next.js, setting the release explicitly using Vercel’s built-in NEXT_PUBLIC_VERCEL_GIT_COMMIT_SHA var seems to work:

Sentry.init({
  // ...
  release: process.env.NEXT_PUBLIC_VERCEL_GIT_COMMIT_SHA,
});

[lobsterkatie]

Thanks for the response @lobsterkatie. Can you say more though? I’m not sure if I fully understand. What would my webpack config look like now?

There wouldn’t be any change on your end. The question is, how are we internally using the webpack plugin? And should we make the change just in the nextjs SDK, or should we do it directly in the webpack plugin?

I’m going to add this to our backlog, and chat with the team about the best way forward.

UPDATE: We decided to just fix this in nextjs to start, as a proof of concept, and then if it works, we’ll think about porting the change over to the webpack plugin. (Since other kinds of apps besides just nextjs apps can be deployed on Vercel, eventually it would be good to fix this everywhere if we can.)