getsentry / getsentry/sentry-javascript
Non-deterministic / changing debug IDs
- Ngôn ngữ chính
- TypeScript
- Star
- 8.7k
- Fork
- 1.8k
- Merge trung bình
- 1 ngày 17 giờ
- Pull request đã merge (30 ngày)
- 515
Mô tả
### 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_
Hướng dẫn đóng góp
Hướng nghiên cứu
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.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Đánh giá
- Công nghệ
- react, typescript, vite
- Lĩnh vực
- build-system, tooling
- Loại issue
- Lỗi
- Độ khó
- 4/5
- Thời gian dự kiến
- 3-5 ngày
- Mức độ hoạt động
- Sôi nổi
- Độ rõ ràng
- Cần làm rõ
- Mức phù hợp với người mới
- 42/100