@sentry/wasm will not work if wasm url is a blob url

[iven]

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/wasm

SDK Version

7.53.1

Framework Version

No response

Link to Sentry event

No response

SDK Setup

No response

Steps to Reproduce

1. Setup @sentry/wasm integration.
2. Init wasm with a blob url returned by URL.createObjectURL().
3. Open the site with browser, and trigger a sentry event.

Expected Result

The event is reported to Sentry.

Actual Result

Browser throws an error TypeError: Failed to construct 'URL': Invalid URL.

I think it's caused by:

sentry-javascript/packages/wasm/src/registry.ts

Line 52 in 8482c0a

debug_file: debugFile ? new URL(debugFile, url).href : null,

Passing a blob:http://xxxx to new URL() is not legal.

[Lms24]

Hi @iven thanks for writing in and for identifying the problematic line of code. We'll take a look at this. We can for sure keep the SDK from throwing an error here but I'm not sure yet if errors from wasm modules loaded as blobs are symbolicated correctly.

[Lms24]

Would you be able to share a minimal reproduction example? I'm curious about how you load your wasm module as a blob. Thanks!

[Lms24]

More background on support for WASM from blobs

Talked about this further offline with @mitsuhiko. With #8263 we definitely fix the error being thrown but it will lead to unsymbolicated stack traces for errors from the WASM module.

To correctly symbolicate frames from WASM modules, we need the file URL. If the module is fetched, like for example here, we currently grab the URL from the fetch response:

sentry-javascript/packages/wasm/src/patchWebAssembly.ts

Lines 15 to 17 in bf9a265

	if (response.url) {
	registerModule(rv.module, response.url);
	}

For modules loaded via blobs or binary streams, etc. (i.e. WASM modules that are not directly fetched), we don't have such an URL (due to the missing response) but the browser internally generates a random url.

We could potentially explore the following:

• if we encounter some sort of binary format, we append a code snippet to the module that will fail
• we catch this error, which should give us the randomly generated url.
• we use this url to register the module which should make our instrumentation/stack frame patching work.