getsentry / getsentry/sentry-javascript
Non-deterministic / changing debug IDs
- 主要语言
- TypeScript
- 星标
- 8.7k
- 派生
- 1.8k
- 平均合并
- 1 天 17 小时
- 30 天内合并 PR
- 523
描述
### Is there an existing issue for this?
- [x] I have checked for existing issues https://github.com/getsentry/sentry-javascript/issues
- [x] I have reviewed the documentation https://docs.sentry.io/
- [x] 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/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-id`s
### 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_
贡献指南
调研方向
Start by reproducing two Vite 8/Rolldown builds from identical inputs and compare the affected chunks' debug IDs. Read the @sentry/vite-plugin release.inject and debug-ID injection paths, then determine whether the residual UUID and import changes originate in the plugin or the build system. Done means the cause is identified and repeated builds no longer produce unexplained debug-ID churn, or a focused upstream issue is documented.
由索引模型根据 Issue 内容生成。
评估
- 技术栈
- react, typescript, vite
- 领域
- build-system, tooling
- Issue 类型
- 缺陷
- 难度
- 4/5
- 预计耗时
- 3-5 天
- 活跃度
- 活跃
- 描述清晰度
- 需要澄清
- 新手友好度
- 42/100