Tim Fish

We could check `process.execArgv` for `--inspect` which would cover a lot of cases. It's still possible to enable the debugger via thge `inspector` api but I suspect this is rarely...

> disable the integration outright at startup if it sees the --inspect flag? Yep, that would be the easiest solution. There is a `Debugger.detached` event but unfortunately nothing for attached....

We actually show this in the [Electron Forge Webpack example](https://github.com/getsentry/sentry-electron/tree/master/examples/electron-forge-webpack) and I should probably update the Vite example to do the same!

Correction, the example app already does this, it just doesn't include the preload yet: https://github.com/getsentry/sentry-electron/blob/master/examples/electron-forge-vite/vite.main.config.mjs https://github.com/getsentry/sentry-electron/blob/master/examples/electron-forge-vite/vite.renderer.config.mjs

@Bruno-DaSilva do you have an example that replicates this? I've tried adding some async into our existing integration tests and still get local variables.

I would be interested in helping maintain too!

Ok so with the async debugger via worker, this results in a memory leak. I guess this needs some cleanup.

> Do we have to worry about object size with a large number of errors? It might be worth adding a limit regardless of how we're passing the variables. >...

Oh it stopped the memory leak but also stopped it from working. Back to the drawing board 😂

I fixed the memory leak while keping the feature actually functioning by delaying the cleanup. Interestingly, although the Node v22 memory leak test fails, the memory usage does drop off...