Skip to content

Support WASM modules instantiated in web workers #18779

@andreiborza

Description

@andreiborza

Problem Statement

The wasmIntegration currently only supports WASM modules instantiated on the main thread. When WASM is instantiated inside a web worker, the integration doesn't fully work:

  • WASM frames are not symbolicated
  • No debug images attached to event.debug_meta.images
  • applicationKey for third-party filtering doesn't apply to WASM frames

This is because:

  1. patchWebAssembly() only patches the main thread's WebAssembly object - workers have their own global scope
  2. The IMAGES registry, that stores WASM debug info, is module-scoped with no mechanism to forward it to the main thread
  3. registerWebWorker() doesn't collect or forward WASM module registration data to the main-thread

Solution Brainstorm

Add a registerWebWorkerWasm() function to @sentry/wasm that users call in their worker:

Main-thread setup:

import * as Sentry from "@sentry/browser";
import { wasmIntegration } from "@sentry/wasm";

Sentry.init({ 
  dsn: '...',
  integrations: [
    wasmIntegration(),
  ],
});

const worker = new Worker("worker.js");

Sentry.addIntegration(Sentry.webWorkerIntegration({ worker }));

Worker setup:

// proposed new api `registerWebWorkerWasm` api

import { registerWebWorkerWasm } from "@sentry/wasm";   
registerWebWorkerWasm({ self }); 

This patches WebAssembly in the worker and fowards debug images to the mainthread via postMessage the same way we do with debugIds and module metadata. It would also help filtering out third-party errors when passing in an applicationKey to the wasmIntegration in the main-thread. This is already implemented but it needs the debug images forwarded from the worker to make use of it.

The existing webWorkerIntegration would need to listen to and store WASM images on the window the same way we do with debugIds and module metadata, i.e. WINDOW._sentryWasmImages

Then the wasm integration's processEvent() will use these stored images from the worker.

This approach mirrors how we do things in workers for debugIds and moduleMetadata.

Additional Context

Discussions: #18766, #18705

Priority

React with 👍 to help prioritize this issue. Please use comments to provide useful context, avoiding +1 or me too, to help us triage it.

Metadata

Metadata

Assignees

Labels

Projects

Status

No status

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions