Open GaurangTandon opened 9 months ago
Hey @GaurangTandon
To support this, it seems like you'll need to sync the scope and sent events across the different processes. An example of how we do this is with the Electron SDK.
An integration that syncs the scope from renderer process to main process: https://github.com/getsentry/sentry-electron/blob/master/src/renderer/integrations/scope-to-main.ts
Logic in the main process that handles IPC from renderer: https://github.com/getsentry/sentry-electron/blob/master/src/main/ipc.ts
I don't think we have the bandwidth to support this as a 1st class integration for now given our other priorities, but happy to help give feedback/review any solutions you try out.
Hi @AbhiPrasad thanks I'll try it out by next week and let you know how it goes.
this would be so cool!
Problem Statement
With the upcoming Manifest V3 changes, almost all powerful extensions will end up having at least three separate extension contexts:
The extension service worker and the offscreen document are completely separate processes. The sandbox is iframed inside the offscreen document.
Coming back to SentryJS...right now, I have added
Sentry.init
andconfigureScope
to all the three contexts. It is working fine. The issue I am facing is that all the breadcrumbs and tag data are separate between the three processes (nothing is shared).So,
Question: what is a feature that SentryJS can implement to better support these use cases. As I mentioned at the beginning, with the upcoming Manifest V3 architecture, this scenario is going to be a lot more common.
Solution Brainstorm
I had one idea: allow me to initialise a "master" sentry context, and then once (at the initialisation step) I will setup the message hooks to connect other Sentry contexts with the master context. Then, from there on, SentryJS can internally use the provided message hooks to propagate updates from master to all the clients, and unify all the breadcrumbs (and other data) whenever any event occurs.