@sentry/nextjs modifies app.js output hash by injecting release value

[sekyungk]

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

9.29.0

Framework Version

React 18.3.1, Next 13.5.11

Link to Sentry event

No response

Reproduction Example/SDK Setup

No response

Steps to Reproduce

1. Use @sentry/nextjs in a Next.js project.
2. Do not set the SENTRY_RELEASE environment variable.
3. Ensure app.tsx has no changes.
4. Build the app with next build.
5. Commit a change (anywhere else in the repo, not in app.tsx) so that the Git commit hash changes.
6. Build again with next build.
7. Compare the two build outputs, especially .next/static/chunks/app-*.js.

➡️ You will see that the hash of app.js has changed even though app.tsx has not been modified.

If you look inside the built app.js, the following line will appear:

...
            return (
              t.push(
                nextjsClientStackFrameNormalizationIntegration({
                  assetPrefix: r,
                  basePath: i,
                  rewriteFramesAssetPrefixPath: n,
                  experimentalThirdPartyOriginStackFrames: a,
                })
              ),
              t
            );
          })(e),
          release: '827cbe163190075f8eaa853f1147d24150bfdd5f',
          ...e,
        };
...

This release value corresponds to the current Git commit hash and is injected automatically into the output by @sentry/nextjs.

This behavior was introduced by this PR.

Expected Result

The build output should be stable and deterministic.

• If files like app.tsx are unchanged, the generated app.js and its hash should remain the same across builds.
• The release value should not be injected into application bundles (like app.js) in a way that changes their content.
• This should apply even if SENTRY_RELEASE is defined

Actual Result

The release field is injected using the current Git commit hash (e.g. '827cbe1631...') even when SENTRY_RELEASE is not defined.
This causes app.js to change and generate a new build hash, even though the source code (like app.tsx) is untouched.

As a result:
Caching is broken

[chargome]

Hey @sekyungk thanks for reaching out!

You are right, but this is currently expected behaviour as we need to inject the release value into the bundles. The only way you would get around this would be to provide your own SENTRY_RELEASE value across builds as this would take precedence here.

Another solution would be for us to move the complexity to the runtime but that is probably not feasible since we want our SDK to init as fast as possible.

cc @RulaKhaled

[sekyungk]

@chargome Thanks for your response.

The only way you would get around this would be to provide your own SENTRY_RELEASE value across builds as this would take precedence here.

As you mentioned, fixing SENTRY_RELEASE value can prevent bundle hash changes caused by release value updates.

However, I may need to inject a meaningful release value (e.g., home-release-1) at the time of Sentry.init.

So I’d like to ask:

Would it work if I put a meaningless, fixed SENTRY_RELEASE value at build time via withSentryConfig, and put the actual meaningful release value (e.g. home-release-1) at runtime via Sentry.init?

If this approach is valid, I believe we will be able to accurately track the release information without problems regarding hash.

[chargome]

@sekyungk the release value should be the same in both places to ensure correct source map association and release tracking

[sekyungk]

@chargome,

The Sentry Next.js SDK will no longer use the Next.js Build ID as fallback identifier for releases. The SDK will continue to attempt to read CI-provider-specific environment variables and the current git SHA to automatically determine a release name. If you examine that you no longer see releases created in Sentry, it is recommended to manually provide a release name to withSentryConfig via the release.name option.
This behavior was changed because the Next.js Build ID is non-deterministic, causing build artifacts to be non-deterministic, because the release name is injected into client bundles.

The Sentry v9 migration docs mention that the issue of releases being injected into client bundles (which caused changes to build artifacts) has been fixed.

But after this PR, the release is again injected into client bundles. So the build artifact still changes depending on the release. I'm wondering — do you not see this as a problem?

Including the release ID in app.js changes its hash every time, which badly affects browser caching.

If there’s no way to avoid this, is it at least possible to split the Sentry chunk out from app.js?