withIsolationScope failed to capture context for unhandled exception inside setInterval

[zhiyan114]

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

9.24.0

Framework Version

Node 22.14.0 LTS

Link to Sentry event

No response

Reproduction Example/SDK Setup

https://github.com/zhiyan114/Firey-Bot/blob/275621a29a3f4181857476fd0a002a83301d91e9/src/services/VoiceChatReward.ts#L77C3-L110C4

In line 81, a user context is attached to the isolation scope, but (unhandled) exception in line 90 didn't capture this information.

The following function is being called here: https://github.com/zhiyan114/Firey-Bot/blob/275621a29a3f4181857476fd0a002a83301d91e9/src/services/VoiceChatReward.ts#L35C4-L35C71

Steps to Reproduce

For minimal reproduction step, the following code should replicate the exact behavior:

• Use withIsolationScope within setTimeout, setTimeout, or equivalent.

import { init, captureException, consoleLoggingIntegration, extraErrorDataIntegration, flush, logger, rewriteFramesIntegration, withIsolationScope, withIsolationScope } from "@sentry/node";

function caller(bk: ()=> Promise<void>) {
    setTimeout(bk, 1000);
}

process.env["SENTRY_RELEASE"] = execSync(`git -C ${__dirname} rev-parse HEAD`).toString().trim(),
init({
    dsn: "someDSN",
    maxValueLength: 1000,
    tracesSampleRate: 0,
    sendDefaultPii: true,
    _experiments: {
      // Enable logs to be sent to Sentry.
      enableLogs: true,
    },
    integrations: [
        extraErrorDataIntegration({
          depth: 3
        }),
        
        consoleLoggingIntegration({ levels: ['log', 'error', 'warn'] }),
        
        rewriteFramesIntegration({
          iteratee(frame) {
            const absPath = frame.filename;
            if(!absPath) return frame;
            frame.filename = `/${path.relative(__dirname, absPath).replace(/\\/g, "/")}`
            return frame;
          }
        }),
      ],
      beforeSend: (a,b) => {
        console.log("Sending Error to Sentry...")
        return a;
      },
      beforeBreadcrumb: (a,b) => {
        console.log(`Sending Breadcrumb to Sentry: ${a.message}`)
        return a;
      },
      beforeSendTransaction: () => null,
      debug: true,
})

caller(async()=>{
  await withIsolationScope(async (scope) => {
        scope.setUser({
            id: 0,
            username: "ROOT",
            Priv: "SuperUser"
        })
        console.log("HIII");
        throw new Error("TESTING!!!!"); // setUser ctx will not be attached
        //captureException(new Error("TESTING!!!!")); // setUser ctx will be attached
    })
});

Expected Result

Unhandled exception are expected to attach user info context that's wrapped around by the withScope

Actual Result

The given context doesn't show up on the dashboard, the workaround is to force all errors to pass through captureException (which then it wouldn't be unhandled).

[s1gr1d]

Hello, we are aware of this and this is documented in the tests here.

The issue you're experiencing is that thrown errors caught by global error handlers lose scope data from the active scope where the error was originally thrown.

The problem occurs because of how and when the error gets captured:

1. Manual captureException: When you call captureException(error) directly inside the withScope callback, it immediately captures the exception using the current active scope at that exact moment. The scope context is available and applied.
2. Thrown errors: When you throw new Error(), the error bubbles up and gets caught by Sentry's global error handlers. By the time these global handlers execute, you're outside the scope context that was active when the error was thrown.

You can use withIsolationScope here as this does not fork the scopes as frequently as withScope does. Here are the docs for the scopes: https://docs.sentry.io/platforms/javascript/guides/node/enriching-events/scopes/#different-kinds-of-scopes

[zhiyan114]

You can use withIsolationScope here as this does not fork the scopes as frequently as withScope does. Here are the docs for the scopes: https://docs.sentry.io/platforms/javascript/guides/node/enriching-events/scopes/#different-kinds-of-scopes

Unfortunately, similar issue also happens when using withIsolationScope. Using the scope fork outside of the mentioned function will allow the forked scope to attach context normally.

[Lms24]

Hey @zhiyan114!

I tried your reproduction and I can reproduce this but unfortunately, this is expected behaviour. Very similarly to what @s1gr1d explained, also the scope of withIsolationScope is only valid within the callback closure. Since the error is bubbling up to the global handler, we're exiting again.

So the question left to answer is, why this works in the test Sigrid linked above. This is not very obvious but there's an important difference: In the test, we don't fork the isolation scope (like when using withIsolationScope) but we actually set the data on the pre-existing isolation scope. This isolation scope is set by our httpIntegration once the request comes in. This this test is using express, and therefore the errorHandler of express actually captures the error and this still happens within the request life cycle. Since the isolation scope is applied outside of the "express realm", it is still active when our express error handler calls captureException.

I don't know much about your project but I'd recommend trying to do the following for your case:

• avoid forking the isolation scope but setting your data on the already active isolation scope via getIsolationScope().
• ^ implies that you have some kind of request/response http lifecycle on your server, where we already create a new isolation scope as early as possible automatically. If you don't have this, make sure to call withIsolationScope as early as possible yourself and ensure that you call captureException yourself.

I opened #16479 to demonstrate that calling withScope in an express app also doesn't retain the data set on that scope on uncaught errors.

Side note: We have discussed being a bit smarter about collecting scope data along the outer borders of scope closures so that this data is not lost but actually kept. There are good reasons for doing as well as not doing it. I'll bring this up with the team again but can't promise that we'll make changes.

related: #11133