feat(browser): Add debugId sync APIs between web worker and main thread

[Lms24]

This PR adds two Browser SDK APIs to let the main thread know about debugIds of worker files:

• webWorkerIntegration({worker}) to be used in the main thread
• registerWebWorker(self) to be used in the web worker

The communication between workers and main thread is established between both APIs and they have to be used both for the sync to work correctly. Another limitation around this approach is that users must set up webWorkerInegration before they register their own message listeners. This ensures that the message from registerWebWorker is not propagated to user-created message listeners. We'll document this thoroughly in docs and I already added a section about this in the JSDoc.

Because of the strict co-dependence of both APIs, I decided to add them in one PR (also makes testing easier).

Usage

// main.js
Sentry.init({...})

const worker = new MyWorker(...);

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

worker.addEventListener('message', e => {...});

// worker.js
Sentry.registerWebWorker({ self });

self.postMessage(...);

Multiple Workers

Multiple workers are also supported:

// main.js
Sentry.init({...})

const worker = new MyWorker(...);
const worker2 = new MyWorker2(...);

Sentry.addIntegration(Sentry.webWorkerIntegration({ worker: [worker, worker2] }));

worker.addEventListener('message', e => {...});

A worker can also be passed to the integration after it was initialized. This is helpful if workers are initialized lazily or at different times:

// main.js
Sentry.init({...})

const worker = new MyWorker(...);

const webWorkerIntegration = Sentry.webWorkerIntegration({ worker });

Sentry.addIntegration(webWorkerIntegration);

worker.addEventListener('message', e => {...});

// sometime later

const lazyWorker = new MyLazyWorker(...);
webWorkerIntegration.addWorker(lazyWorker);
lazyWorker.addEventListener('message', e => {...});

I decided to keep both APIs very general around web workers because I think there could be other use cases in which we can sync data by using the worker's message channels. This should be as easy as listening for other messages.

also added

• unit tests for the two APIs
• integration test testing the webWorkerIntegration
• e2e test demonstrating correct usage of both APIs together

closes #16975
closes #16976

To fix the issue, we need to ensure that the origin of incoming messages is checked before processing them. In the context of web workers, the event.origin property is not available. Instead, we should verify the source of the message via event.source or other data provided in the message, such as custom identifiers or tokens.

In this case, we can use a simple check to ensure that the incoming message contains a specific trusted property (e.g., _sentryMessage) or other predefined criteria. If the criteria are not met, the message should be ignored.

---

The fix involves verifying the origin of incoming messages in the message event handler before processing them. This ensures that only messages from trusted sources are acted upon. Specifically:

1. Identify the trusted origin (e.g., 'https://www.example.com').
2. Add a conditional check in the message event handler to validate the origin of incoming messages against this trusted value.
3. Only proceed with processing the message if the origin matches the trusted value.

No new imports or dependencies are required to implement this fix.

---

[Lms24]

adjusted this message because I didn't realize the volta config needed to be added to the e2e test apps. Might be a me-problem but I think the message is now fool-proof :D

[timfish]

LGTM.

What happens if you have more than one worker and try and add them both? If you add the integration twice will it remove the one you added first?

[Lms24]

What happens if you have more than one worker and try and add them both? If you add the integration twice will it remove the one you added first?

Good point, thanks for raising! The first installed integration wins and the second instance wouldn't be added (=> setupOnce wouldn't be called and debugIds not added).

I think we have a couple of options:

1. We can let the integration accept an array of workers instead. This assumes though that all workers are initialized at the same time. Which seems unlikely.
2. We can add a method on the integration (webWorkerIntegration.addWorker(worker)), similarly to how the replay and feature flag integrations work. This increases complexity of the integration (or rather typing-wise) but still comes with the benefit that everything can be handled within one integration.
3. We could also move away from making the main thread part an integration at all but just a regular function (e.g. Sentry.instrumentWorker()` or something similar). I wanted to go with the integration because it's a well-known pattern and seemed fitting. But maybe we should revisit.

I'm tentatively tending towards 2 but don't yet have a strong opinion. Any thoughts on this? Will also take it to the team to discuss shortly.

(set the PR to draft in the meantime)

[timfish]

Another possibly more hacky solution is to set a different name for each instance of the Integration:

let count = 0;

export const webWorkerIntegration = defineIntegration(({ worker }: WebWorkerIntegrationOptions) => ({
  name: `${INTEGRATION_NAME}-${count++}`,
  setupOnce: () => {

Since this integration isn't default included users wont need to use the name to filter it out and because the name differs, multiples can be added?

To fix the issue, the postMessage handler should verify the origin of the incoming message to ensure it comes from a trusted source. This involves:

1. Adding a conditional check for event.origin against a predefined trusted origin (e.g., 'https://trusted-origin.com').
2. Ensuring that only messages from the trusted origin are processed, while others are ignored.

The fix will involve modifying the self.addEventListener('message', ...) block to include the origin verification logic. No additional imports or dependencies are required.

---

To fix the issue, we need to validate the source of the incoming message in the Web Worker. Since the origin property is not available in Web Workers, we can use a custom property in the event.data object (e.g., source) to identify trusted messages. The main thread should include this property when sending messages to the worker, and the worker should verify it before processing the message.

1. Modify the self.addEventListener('message', ...) handler to include a check for a trusted source property in the event.data object.
2. Ensure that only messages with the expected source value are processed.

---

[Lms24]

I went with options 1 and 2 combined. Decided to do it "properly" instead of the "hack" (though I liked the suggestion) to avoid the side effect it would introduce and to keep the integration name constant. Not sure why users would look up or remove the integration but let's keep the integration names predictable.

[timfish]

Looks good!