Crypto-wasm asset changes hash between builds

[hughns]

Steps to reproduce

1. Build element-call.
2. Note the hash for the crypto-warm asset.
3. Change something in element-call but keep the same crypto-wasm version.
4. Build element-call again.
5. Check the crypto-wasm asset again to see what hash was allocated.
6. See that it is different than before.

Outcome

What did you expect?

The asset hash would depend on the npm version. So, if the npm version hasn’t changed then the asset name would be the same and there is some chance that the browser will have cached the asset.

What happened instead?

The asset hash changed even though the npm version was the same.

Operating system

No response

Browser information

No response

URL for webapp

No response

Will you send logs?

No

[hughns]

I had a look at this and the reproduction steps don't work locally.

However, I did look at what is different between asset versions and it is the Sentry integration. It appears that somewhere during the build two globals get set which are making their way tino the crypto-wasm:

< (function(){try{var G=typeof window<"u"?window:typeof global<"u"?global:typeof self<"u"?self:{},L=new G.Error().stack;L&&(G._sentryDebugIds=G._sentryDebugIds||{},G._sentryDebugIds[L]="885f9588-d54f-4e43-8949-fe408c9d6558",G._sentryDebugIdIdentifier="sentry-dbid-885f9588-d54f-4e43-8949-fe408c9d6558")}catch{}})();var DQ=typeof window<"u"?window:typeof global<"u"?global:typeof self<"u"?self:{};DQ.SENTRY_RELEASE={id:"43455bdf71384f8b42ee306f3ddc847358f7fa82"};var GQ=typeof globalThis<"u"?globalThis:typeof window<"u"?window:typeof global<"u"?global:typeof self<"u"?self:{};function NQ(G){return G&&G.__esModule&&Object.prototype.hasOwnProperty.call(G,"default")?G.default:G}function YQ(G){if(G.__esModule)return G;var L=G.default;if(typeof L=="function"){var g=function S(){return this instanceof S?Reflect.construct(L,arguments,this.constructor):L.apply(this,arguments)};g.prototype=L.prototype}else g={};return Object.defineProperty(g,"__esModule",{value:!0}),Object.keys(G).forEach(function(S){var V=Object.getOwnPropertyDescriptor(G,S);Object.defineProperty(g,S,V.get?V:{enumerable:!0,get:function(){return G[S]}})}),g}function oQ(G){throw new Error('Could not dynamically require "'+G+'". Please configure the dynamicRequireTargets or/and ignoreDynamicRequires option of @rollup/plugin-commonjs appropriately for this require call to work.')}var Lg={exports:{}},pg,VI;function qI(){return VI||(VI=1,pg=`AGFzbQEAAAABqgdhYAF/AGACf38AYAJ/fwF/YAN/f38AYAF/AX9gBH9/f38AYAN/f38Bf2AFf39/
---
> (function(){try{var G=typeof window<"u"?window:typeof global<"u"?global:typeof self<"u"?self:{},L=new G.Error().stack;L&&(G._sentryDebugIds=G._sentryDebugIds||{},G._sentryDebugIds[L]="916916ac-644f-4c96-84ce-5623368af58a",G._sentryDebugIdIdentifier="sentry-dbid-916916ac-644f-4c96-84ce-5623368af58a")}catch{}})();var DQ=typeof window<"u"?window:typeof global<"u"?global:typeof self<"u"?self:{};DQ.SENTRY_RELEASE={id:"4fab1a25b4ad1a263dad15c8dec0f98a1e5fbac0"};var GQ=typeof globalThis<"u"?globalThis:typeof window<"u"?window:typeof global<"u"?global:typeof self<"u"?self:{};function NQ(G){return G&&G.__esModule&&Object.prototype.hasOwnProperty.call(G,"default")?G.default:G}function YQ(G){if(G.__esModule)return G;var L=G.default;if(typeof L=="function"){var g=function S(){return this instanceof S?Reflect.construct(L,arguments,this.constructor):L.apply(this,arguments)};g.prototype=L.prototype}else g={};return Object.defineProperty(g,"__esModule",{value:!0}),Object.keys(G).forEach(function(S){var V=Object.getOwnPropertyDescriptor(G,S);Object.defineProperty(g,S,V.get?V:{enumerable:!0,get:function(){return G[S]}})}),g}function oQ(G){throw new Error('Could not dynamically require "'+G+'". Please configure the dynamicRequireTargets or/and ignoreDynamicRequires option of @rollup/plugin-commonjs appropriately for this require call to work.')}var Lg={exports:{}},pg,VI;function qI(){return VI||(VI=1,pg=`AGFzbQEAAAABqgdhYAF/AGACf38AYAJ/fwF/YAN/f38AYAF/AX9gBH9/f38AYAN/f38Bf2AFf39/

[hughns]

Two "solutions" for this:

1. Wait for Release v12.0.0  matrix-org/matrix-rust-sdk-crypto-wasm#173 to land which will mean that the large file is a .wasm asset which @sentry/vite-plugin won't touch.
2. Set release.inject to be false and then figure out how to make sure that the release info still makes it through to Sentry perhaps via the call to Sentry.init().

[hughns]

PR to try out v12 is at #2903

[hughns]

Two "solutions" for this:

1. Wait for Release v12.0.0  matrix-org/matrix-rust-sdk-crypto-wasm#173 to land which will mean that the large file is a .wasm asset which @sentry/vite-plugin won't touch.

This has now been done in #2911

It mitigates the specific issue with crypto-wasm.

2. Set release.inject to be false and then figure out how to make sure that the release info still makes it through to Sentry perhaps via the call to Sentry.init().

An implementation of this is available for testing at #2913