getsentry / getsentry/sentry-javascript

Non-deterministic / changing debug IDs

Aperta
#23,448 2 commenti 1 reazione 0 assegnatari Vedi su GitHub
Bug post-hackweek React
Lingua principale
TypeScript
Stelle
8.7k
Fork
1.8k
Merge medio
1g 17h
PR unite (30g)
523

Descrizione

### 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_

Guida per i contributori

Apri la guida per i contributori

Direzione di ricerca

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.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Valutazione

Stack tecnologico
react, typescript, vite
Ambito
build-system, tooling
Tipo di issue
Bug
Difficoltà
4/5
Tempo stimato
3-5 giorni
Stato di attività
Attiva
Chiarezza
Da chiarire
Idoneità per principianti
42/100

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.