Repository navigation
@sentry/nextjs modifies app.js output hash by injecting release value #16593
Description
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
- Use @sentry/nextjs in a Next.js project.
- Do not set the SENTRY_RELEASE environment variable.
- Ensure app.tsx has no changes.
- Build the app with next build.
- Commit a change (anywhere else in the repo, not in app.tsx) so that the Git commit hash changes.
- Build again with next build.
- 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
Reacted by lucas0530, nk-lim, Chanyeon, 박민, LeeMir, HYUNGU KANG, al-bur and tobiaspickel
Metadata
Metadata
Assignees
Projects
- Status
Activity
chargome commentedon Jun 17, 2025
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 commentedon Jun 19, 2025
@chargome Thanks for your response.
As you mentioned, fixing
SENTRY_RELEASEvalue 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_RELEASEvalue 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 commentedon Jun 20, 2025
@sekyungk the release value should be the same in both places to ensure correct source map association and release tracking
sekyungk commentedon Jun 22, 2025
@chargome,
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?
chargome commentedon Jun 23, 2025
You can go on with this approach generally although it's not recommended – you'll also need to sync the release value between your client and server init.
What we could do though is stop injecting the value if the
release.createis set tofalse– which would give you back deterministic builds.fix(nextjs): Stop injecting release value when create release options…
github-actions commentedon Jun 25, 2025
A PR closing this issue has just been released 🚀
This issue was referenced by PR #16695, which was included in the 9.32.0 release.