getsentry / getsentry/sentry-javascript

Non-deterministic / changing debug IDs

Ouverte
#23,448 2 commentaires 1 réaction 0 personnes assignées Voir sur GitHub
Bug post-hackweek React
Langage dominant
TypeScript
Étoiles
8.7k
Forks
1.8k
Merge moyen
1 j 17 h
PR mergées (30 j)
523

Description

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

Guide de contribution

Ouvrir le guide de contribution

Piste de recherche

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.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Évaluation

Stack technique
react, typescript, vite
Domaine
build-system, tooling
Type d'issue
Bug
Difficulté
4/5
Temps estimé
3-5 jours
Activité
Active
Clarté
À clarifier
Accessibilité débutants
42/100

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.