Node Local Variables does not seem to work with ESM

[AbhiPrasad]

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 package are you using?

@sentry/node

SDK Version

7.32.0

Framework Version

No response

Link to Sentry event

No response

SDK Setup

import * as Sentry from '@sentry/node';

Sentry.init({
 debug: true,
 beforeSend: (event) => {
 console.log(event.exception.values[0].stacktrace.frames[7]);
 return null;
 },
 dsn: "https://00000000000000000000000000000000@o000000.ingest.sentry.io/0000000",
 includeLocalVariables: true,
});

class Some {
 two(name) {
 throw new Error("Error with local variables");
 }
}

function one(name) {
 const arr = [1, "2", null];
 const obj = {
 name,
 num: 5,
 };

 const ty = new Some();

 ty.two(name);
}

one("some name");

Steps to Reproduce

https://discord.com/channels/621778831602221064/621786575591702529/1070801390223503502

Raised by @lbogdan (thanks!)

https://codesandbox.io/p/sandbox/node-sentry-local-variables-test-hg6zgb?file=%2Findex.js&selection=%5B%7B%22endColumn%22%3A18%2C%22endLineNumber%22%3A31%2C%22startColumn%22%3A1%2C%22startLineNumber%22%3A1%7D%5D

Expected Result

It works

Actual Result

ESM seems to be working with the inspector module differently.

[AbhiPrasad]

I did some troubleshooting by console.log()-ing stuff in localvariables.js, and this is the only thing I get for ESM:
callFrames:

[
 {
 callFrameId: '5267896397716304664.1.0',
 functionName: 'run',
 functionLocation: { scriptId: '453', lineNumber: 188, columnNumber: 11 },
 location: { scriptId: '453', lineNumber: 193, columnNumber: 24 },
 url: '',
 scopeChain: [
 {
 type: 'local',
 object: {
 type: 'object',
 className: 'Object',
 description: 'Object',
 objectId: '5267896397716304664.1.2'
 },
 name: 'run',
 startLocation: { scriptId: '453', lineNumber: 188, columnNumber: 11 },
 endLocation: { scriptId: '453', lineNumber: 219, columnNumber: 3 }
 },
 {
 type: 'closure',
 object: {
 type: 'object',
 className: 'Object',
 description: 'Object',
 objectId: '5267896397716304664.1.3'
 },
 startLocation: { scriptId: '453', lineNumber: 0, columnNumber: 0 },
 endLocation: { scriptId: '453', lineNumber: 223, columnNumber: 0 }
 },
 {
 type: 'global',
 object: {
 type: 'object',
 className: 'global',
 description: 'global',
 objectId: '5267896397716304664.1.4'
 }
 }
 ],
 this: {
 type: 'object',
 className: 'ModuleJob',
 description: 'ModuleJob',
 objectId: '5267896397716304664.1.5'
 }
 }
]

(that's logged from _handlePaused())

[AbhiPrasad]

What could maybe help as a first step is to add some tests for esm!

[timfish]

Whats the betting it has something to do with the params we're passing for Runtime.getProperties...
https://github.com/nodejs/node/blob/1118db718c8429f5f343aca90ccb570244e282b4/test/parallel/test-inspector-esm.js#L67-L75

[lbogdan]

To me it seems that the callFrames received in _handlePaused() have a lot less context in ESM than CJS - it only contains one frame, probably from wrapper code generated by the runtime, judging by the functionName: 'run' (top-level await & co.), vs. 4 in CJS.

[timfish]

Yep, there's only one call frame:

 {
 callFrameId: '322533888473365029.1.0',
 functionName: 'run',
 functionLocation: { scriptId: '111', lineNumber: 187, columnNumber: 11 },
 location: { scriptId: '111', lineNumber: 192, columnNumber: 24 },
 url: 'node:internal/modules/esm/module_job',
 scopeChain: [ [Object], [Object], [Object] ],
 this: {
 type: 'object',
 className: 'ModuleJob',
 description: 'ModuleJob',
 objectId: '322533888473365029.1.5'
 }
 }

[lbogdan]

Hm, looks like all the main script / module's context is lost by the time the error is caught by the runtime, even the async frames only contain runtime stuff:

[lbogdan]

For reference, here's how it looks like just before the main script / module starts executing:

[timfish]

looks like all the script's context is lost at the time of the error

It does appear in the above case of uncaught error while loading the module, the context is lost and not accessible via the debugger. Does anyone know if this behaviour is documented somewhere?

If I enable debugging caught exceptions (new LocalVariables({ captureAllExceptions: true })) it does capture local variables when wrapped in try/catch. I did find a small bug in frame matching with esm (#7049).

I also found that making one async and calling it without awaiting also results in local variables being attached, but again only if captureAllExceptions is enabled. I would have expected this to be categorised as uncaught:

async function one(name) { //

one('some name');