Is there an existing issue for this?
How do you use Sentry?
Sentry Saas (sentry.io)
Which SDK are you using?
@sentry/react
SDK Version
10.70.0
Framework Version
10.70.0
Link to Sentry event
No response
Reproduction Example/SDK Setup
No response
Steps to Reproduce
When building with the @sentry/vite plugin, we are getting certain files with a debug-id that changes every time the app is built. Most files don't have this turnover, as long as the sentry app version isn't set explicitly in each file.
It's unclear to me whether this is a rolldown issue or what; it doesn't affect
Expected Result
Files do not change when built twice from the same inputs.
Actual Result
Changes to the files' debug-ids
Additional Context
We currently build with Vite 8 (Rolldown) and use @sentry/vite-plugin for release management and sourcemap upload. Currently, we're using content hashing, though not any of the experimental options for vite 8. From what I remember, these chunks were stable under vite 7.
We already found and fixed one source of hash churn: the plugin's release.inject option was writing the git SHA into every chunk's prelude, so all ~340 chunks rehashed on every deploy regardless of content. Disabling that fixed most issues in all but 15-25 files.
With that fixed, a smaller, consistent residual remains: 4–5 chunks still get a new hash on every build, with no source changes. When diffing two builds of the same commit, two patterns show up:
In "seed" chunks, only the debug-id UUID differs. The files are identical, except the UUID embedded in Sentry's injected snippet: e._sentryDebugIds[t]="9baadc63-9d15-4978-aea5-b51262d48eb5"
The code, imports, etc., are the same; just a different UUID baked in.
In "cascade" chunks, we see the UUID change, plus one changed import specifier
We are investigating just using the CLI for now to work around this issue, since having these files change every time we deploy (4-5 at least) is causing a lot of extra turnover that isn't really needed when the main app already has its hash change on each build.
Unfortunately, creating an exact public repro case will be difficult, however, I'm happy to provide more information to Sentry support if desired.
Priority
No response
Is there an existing issue for this?
How do you use Sentry?
Sentry Saas (sentry.io)
Which SDK are you using?
@sentry/react
SDK Version
10.70.0
Framework Version
10.70.0
Link to Sentry event
No response
Reproduction Example/SDK Setup
No response
Steps to Reproduce
When building with the
@sentry/viteplugin, we are getting certain files with a debug-id that changes every time the app is built. Most files don't have this turnover, as long as the sentry app version isn't set explicitly in each file.It's unclear to me whether this is a rolldown issue or what; it doesn't affect
Expected Result
Files do not change when built twice from the same inputs.
Actual Result
Changes to the files'
debug-idsAdditional Context
We currently build with Vite 8 (Rolldown) and use
@sentry/vite-pluginfor release management and sourcemap upload. Currently, we're using content hashing, though not any of the experimental options for vite 8. From what I remember, these chunks were stable under vite 7.We already found and fixed one source of hash churn: the plugin's
release.injectoption was writing the git SHA into every chunk's prelude, so all ~340 chunks rehashed on every deploy regardless of content. Disabling that fixed most issues in all but 15-25 files.With that fixed, a smaller, consistent residual remains: 4–5 chunks still get a new hash on every build, with no source changes. When diffing two builds of the same commit, two patterns show up:
In "seed" chunks, only the debug-id UUID differs. The files are identical, except the UUID embedded in Sentry's injected snippet:
e._sentryDebugIds[t]="9baadc63-9d15-4978-aea5-b51262d48eb5"The code, imports, etc., are the same; just a different UUID baked in.
In "cascade" chunks, we see the UUID change, plus one changed import specifier
We are investigating just using the CLI for now to work around this issue, since having these files change every time we deploy (4-5 at least) is causing a lot of extra turnover that isn't really needed when the main app already has its hash change on each build.
Unfortunately, creating an exact public repro case will be difficult, however, I'm happy to provide more information to Sentry support if desired.
Priority
No response