Injected debug id causing hash differences in cross-architecture builds

[Redmega]

Is there an existing issue for this?

• I have checked for existing issues https://github.com/getsentry/sentry-javascript/issues
• I have reviewed the documentation https://docs.sentry.io/
• 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/nextjs

SDK Version

^9.5.0

Framework Version

next ^14.2.24

Link to Sentry event

No response

Reproduction Example/SDK Setup

No response

Steps to Reproduce

1. Use [contenthash] in place of [chunkhash] for consistent cross-architecture builds
2. Build docker image for multiple architectures
3. Note that each build has generated a different debugId, which causes the contenthash to change.

Expected Result

Content hashes should be consistent across architectures. I think we can accomplish this by specifying which hash the debugId uses, I suspect it's using the id/chunkhash and not the contenthash?

Actual Result

Content hashes are different across architectures. Similar to the issue described in #13971

[andreiborza]

Hi @Redmega, thanks for filing this.

Afaik, debug ids are generated based on code, hashes are stripped from the file endings. Are you observing consistent hashes without Sentry?

cc @lforst

[lforst]

What are you using to inject debug IDs? The CLI? If so, it should inject a deterministic uuid based on file-content.

[Redmega]

What are you using to inject debug IDs? The CLI? If so, it should inject a deterministic uuid based on file-content.

Sorry, not sure why I had @sentry/browser in the opening comment, I'm using @sentry/nextjs. I must have overlooked that.

We also use nx and this is how my config ends up looking with plugin composition:

  nxComposePlugins(withNx, withBundleAnalyzer, (config) => withSentryConfig(config, sentryConfig))(nextConfig);

Afaik, debug ids are generated based on code, hashes are stripped from the file endings. Are you observing consistent hashes without Sentry?

Yes, hashes are consistent between architectures when not using the sentry plugin (caveat: I replace [chunkhash] with [contenthash] as the arm/amd builds were generating different chunkhashes):

ARM (No Sentry)

├ chunks/framework-6d28727e634f0245.js   44.9 kB
├ chunks/main-3455d129e2595baf.js        32.3 kB
├ chunks/pages/_app-7c7a48c21a77f379.js  824 kB
├ css/ac0fbf6c8e1d87bd.css               36.1 kB

AMD (No Sentry)

├ chunks/framework-6d28727e634f0245.js   44.9 kB
├ chunks/main-3455d129e2595baf.js        32.3 kB
├ chunks/pages/_app-7c7a48c21a77f379.js  824 kB
├ css/ac0fbf6c8e1d87bd.css               36.1 kB

I also went into the differently hashed files (in this case it was only _app-*.js) and confirmed that when the sentry debug injected code was removed, the files hashed identically and had no diff.

ARM (Sentry)

├ chunks/pages/_app-40949006ebec3ca7.js  865 kB

AMD (Sentry)

├ chunks/pages/_app-bc03ec9e4895a4b6.js  865 kB

Looking at the logs, I suspect that sentry is injecting the code before nextjs has calculated the hashes and output the files, so when nextjs calculates the contenthash they are different. As to why the uuid is different between the two architectures for the same file contents, I'm not sure. I need to dig into the intermediary steps more.

[Redmega]

Actually, in the webpack plugin which is what the nextjs plugin uses under the hood I believe? hash is used instead of contenthash.

const debugId = arg?.chunk?.hash ? stringToUUID(arg.chunk.hash) : uuidv4();

It's my understanding that hash is generated per-build so because we have to build on each architecture, we have two builds, and therefore two hashes. Either that or the hash differs because of the architecture itself. I think this explains why the uuid differs between the two architectures, and a possible fix is to use contenthash and not hash from the chunk.

[Redmega]

As a workaround I wrote a plugin to patch the BannerPlugin added by sentry to look at contentHash instead of hash. Now my build artifacts match across architectures.

class SentryDebugIdPatchPlugin {
  wrapBanner(bannerPlugin) {
    bannerPlugin.banner = (arg) => {
      if (arg?.chunk?.contentHash?.javascript) {
        return bannerPlugin.options.banner({ chunk: { hash: arg.chunk.contentHash.javascript } });
      }
      return bannerPlugin.options.banner(arg);
    };
  }

  apply(compiler) {
    const bannerPlugin = compiler.options.plugins.find(
      (p) => p.constructor.name === "BannerPlugin" && p.banner?.toString().includes("getDebugIdSnippet"),
    );
    this.wrapBanner(bannerPlugin);
  }
}

I think an option to use the content hash instead of the chunk hash would be ideal for usecases like this.