Support and assign debugIds from web worker in main thread #16974

Problem Statement

Today, you can initialize the Sentry SDK in the main thread and it will capture errors thrown in a web worker (at least in regular workers; not sure about service workers). If users add source map upload via debug ids however, it's not easily possible right now, to correctly symbolicate the errors from the worker.

This is because, the global object in the worker self contains the debugId for its file(s) and the main thread only contains the debugIds of its files on window. Since there's no shared global object, there's no place where all of these debugIds are present. When we assign the debugIds to the error event, we can only access the main thread's global and therefore, the SDK has no knowledge of the debugIds of the worker's file(s).

There is a (sub-optimal) solution to "fix" this today: Init the SDK another time in the worker. This will make the SDK in the worker capture the error, look up the correct debugId and send it to Sentry. There are (at least) two significant drawbacks though:

• In my testing, the error still bubbled up to the main thread's global handler and Sentry captured it twice (apparently our dedupe logic doesn't work for this case)
• obviously, all worker errors lose the trace context, replay connection, etc of the main thread

Solution Brainstorm

Well if we don't want to double init the SDK, we need to let the main thread know about the debugIds of the worker.

This could look as follows:

// main.js
Sentry.init();

const worker = new MyWorker();

Sentry.addIntegration(Sentry.webWorkerIntegration(worker))

// myWorker.js
Sentry.registerWorker(self)

Internally, both APIs communicate over the worker's message channel:

• registerWorker reads the debugIds from self and posts a message with them
• webWorkerIntegration listens for the message and, once received, writes the debugId key-value pairs onto its global window._sentryDebugIds object.

Now, once the worker throws an error that's caught by the SDK, it will be able to pick up the debugId for the stack frames from the worker and attach them --> event in Sentry ends up symbolicated.#

Besides symbolicated events, this now also has the advantage that the worker errors will get the same traceId as the main thread, as well as replayId connections being made. So all in all a better experience.

I have a PoC of this working -- the new SDK APIs would probably look very similar.