Sentry sending the wrong release when capturing an exception

[jonathanhuang13]

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 #4373

[lforst]

Hi, Thanks for writing in and providing such a detailed issue description!

It might very well be that Vercel is caching the files where we inject the release. Given that I have only little experience with Vercel, this is the first time I've actually noticed that they're caching stuff (so here are some links for posterity: 1, 2).

Do you have any experience around the Vercel build cache and have suggestions on how we could go about fixing this?

[jonathanhuang13]

Hi @lforst, thanks for the response. Here's one more link that Next.js provides (although it's not very detailed). I'm also not very familiar with Vercel build cache, but I think it uses Webpack 5 under-the-hood so I wonder if a Webpack config could fix the issue

[AbhiPrasad]

I wonder if there's a way to selectively bust the cache for the files where we are injecting the release - but I think asking the nextjs folks will help point you in the right direction.

One thing that might work is to explicitly set the release everywhere. So you would take and use the VERCEL_GITHUB_COMMIT_SHA everywhere, instead of making the SDK and webpack plugin infer it.

[jonathanhuang13]

Okay I started a discussion here in Next.js.

I just tried setting the SENTRY_RELEASE but had no luck. Just to confirm, I only set the environment variable at build time like so:

• vercel --build-env SENTRY_RELEASE=foo - Vercel uses the Next.js cache and the result is that Sentry uses the old release value
• vercel --build-env SENTRY_RELEASE=foo --force - Vercel doesn't use the Next.js cache (because of --force) and the result is that Sentry's release value is now foo

[lobsterkatie]

One way I think we could fix this would be to change how the release is injected. Right now, @sentry/webpack-plugin creates a file which it then adds to the webpack entry property of all files specified in the plugin's include option, and it sounds like that file is what's being cached. There's no reason we couldn't just use our prefixLoader, though. All it would take is grabbing the boilerplate which gets injected into that file and adding it to our template instead.

[jonathanhuang13]

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?

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

[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,
});