Sentry changing worker thread error behavior

[mohd-akram]

Is there an existing issue for this?

• I have checked for existing issues https://github.com/getsentry/sentry-javascript/issues
• I have reviewed the documentation https://docs.sentry.io/
• I am using the latest SDK release https://github.com/getsentry/sentry-javascript/releases

How do you use Sentry?

Sentry Saas (sentry.io)

Which SDK are you using?

@sentry/node

SDK Version

10.32.1

Framework Version

No response

Link to Sentry event

No response

Reproduction Example/SDK Setup

instrument.js:

import * as Sentry from "@sentry/node";
Sentry.init();

main.js:

import { Worker } from "worker_threads";

export function runJob() {
  const worker = new Worker("./job.js");
  return new Promise((resolve, reject) => {
    worker.once("error", reject);
    worker.once("exit", (code) => {
      if (code) reject(new Error(`Worker exited with code ${code}`));
      else resolve();
    });
  });
}

try {
  await runJob();
} catch (err) {
  console.error("caught", err);
}

job.js

throw new Error("job failed");

package.json

{
  "type": "module",
  "dependencies": {
    "@sentry/node": "^10.32.1"
  }
}

Steps to Reproduce

1. Run node main.js
2. Run SENTRY_DSN=dsn node --import ./instrument.js main.js
3. Compare results

Expected Result

caught Error: job failed
    at job (file:///private/tmp/sentry-test/job.js:2:9)
    at file:///private/tmp/sentry-test/job.js:5:7
    at ModuleJob.run (node:internal/modules/esm/module_job:377:25)
    at process.processTicksAndRejections (node:internal/process/task_queues:105:5)
    at async onImport.tracePromise.__proto__ (node:internal/modules/esm/loader:691:26)
    at async asyncRunEntryPointWithESMLoader (node:internal/modules/run_main:101:5)

Actual Result

Error: job failed
    at job (file:///private/tmp/sentry-test/job.js:2:9)
    at file:///private/tmp/sentry-test/job.js:5:7
    at ModuleJob.run (node:internal/modules/esm/module_job:377:25)
    at async onImport.tracePromise.__proto__ (node:internal/modules/esm/loader:691:26)
    at async asyncRunEntryPointWithESMLoader (node:internal/modules/run_main:101:5)
caught Error: Worker exited with code 1
    at Worker.<anonymous> (file:///private/tmp/sentry-test/main.js:8:24)
    at Object.onceWrapper (node:events:623:26)
    at Worker.emit (node:events:508:28)
    at [kOnExit] (node:internal/worker:379:10)
    at Worker.<computed>.onexit (node:internal/worker:293:20)

Additional Context

No response

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.}

[linear]

JS-1347

[s1gr1d]

Hello and thanks for writing in!
Am I understanding it correctly that you noticed the stack trace being different when using Sentry?

It could happen because of the childProcessIntegration (docs) where the default settings might interfere with the error handling. Would setting captureWorkerErrors: false make a difference?

[JPeer264]

I just double checked. It is caused from our OnUncaughtException integration. If you want, you can disable it:

Sentry.init({
  integrations: (integrations) =>
    integrations.filter(
      (integration) => integration.name !== "OnUncaughtException"
    ),
});

[mohd-akram]

Hello and thanks for writing in! Am I understanding it correctly that you noticed the stack trace being different when using Sentry?

It could happen because of the childProcessIntegration (docs) where the default settings might interfere with the error handling. Would setting captureWorkerErrors: false make a difference?

The issue is that Sentry is changing the semantics of the program. Per the Node.js docs, an uncaught exception in a worker thread causes an error event to be emitted to the Worker object. Then, an exit event is emitted with code 1. Without Sentry, the worker thread throws causing an error event where the promise is rejected. The second rejection in the exit event is ignored as expected. With Sentry, the error event is never received, and the error is printed to the console. Instead, the promise only gets rejected due to the exit event and therefore the error created there is what is caught.

It could happen because of the childProcessIntegration (docs) where the default settings might interfere with the error handling. Would setting captureWorkerErrors: false make a difference?

This does not seem to make a difference.

I just double checked. It is caused from our OnUncaughtException integration.

Disabling this integration resolves the issue, but this is not desirable since I would want to log uncaught exceptions. It seems Sentry does not use uncaughtExceptionMonitor which would likely avoid these problems. I see #11431 was closed with the reason that uncaughtExceptionMonitor does not handle unhandled rejections, but the Node.js docs say it does.