Repository navigation
Non-deterministic / changing debug IDs #23448
Description
Activity
Hi, we are currently on a company-wide hackweek and will get back to issue triaging August 24th. We'll take another look then.
- moved this from Waiting for: Product Owner to No status in GitHub Issues with 👀 3
on Aug 18, 2026 1 remaining item
- moved this from Waiting for: Product Owner to No status in GitHub Issues with 👀 3
on Sep 29, 2026 @wyardley thanks again for filing this. Looks like @chen-anders opened a PR for this. We are going through a rounds of reviews for this.
- added a commit that references this issue
on Oct 1, 2026 A PR closing this issue has just been released 🚀
This issue was referenced by PR #24919, which was included in the 11.3.0 release.
Can someone just confirm for me what the path is to fix? Seems based on https://github.com/getsentry/sentry-javascript-bundler-plugins/releases/tag/5.4.0 that I should wait for the vite plugin v 11 to get published?
@sentry/bundler-pluginsgets published alongside the SDKs. Sorry, I'm currently working on a docs migration to cover this!Ah, so install it as a dev dependency / peer dependency along with the 5.x vite plugin?
That's kind of where I landed but wanted to make sure that was correct.
Which JavaScript SDK are you using? Some SDKs export the bundler plugins directly.
Generally, uf you are using v11 of the JavaScript SDKs, install a matching version of
@sentry/bundler-pluginsas a dev dependency and use the plugin exported from@sentry/bundler-plugins/vite.Currently, we just have:
"@sentry/browser": "^10.70.0", "@sentry/react": "^10.70.0", "@sentry/vite-plugin": "^5.4.0",Currently, that gets us
@sentry/bundler-plugins@10implicitly via@sentry/vite-plugin, so my preference is not to directly pull in@sentry/bundler-pluginsunless that's the suggested / best practice. The release notes I linked to above imply that"@sentry/vite-pluginv11 would go after v5, and would assume that one will have bundler-plugins@11 as a dependency or peerDependency, unless there's a new way of doing thisSeems like for v11, just replace vite-plugin with bundler-plugins, and do:
+import { sentryVitePlugin } from '@sentry/bundler-plugins/vite';?
Seems like for v11, just replace vite-plugin with bundler-plugins, and do:
+import { sentryVitePlugin } from '@sentry/bundler-plugins/vite';Yes!
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