module.register() will hang when debugging

[mxschmitt]

Describe the bug

Debugging a JavaScript file which leverages module.register does end up in a infinite hang.

To Reproduce

// loader.js
module.exports = {
  initialize: ({ number, port }) => {
    port.postMessage(`increment: ${number + 1}`)
  }
}

// test.js
const { pathToFileURL } = require('url');
const { port1, port2 } = new MessageChannel();

port1.on('message', (msg) => {
  console.log(msg);
});
port1.unref()

console.log('before')
require('node:module').register(pathToFileURL(require.resolve('./loader.js')), {
  parentURL: pathToFileURL(__filename),
  data: {
    number: 1,
    port: port2
  },
  transferList: [port2],
});
console.log('after')

(following their example)

Steps to reproduce the behavior:

1. node test.js

Log File

N/A

VS Code Version: 1.90.0

Additional context

Looks like fixed in VSCode insiders - wasn't able to reproduce it there.

Version: 1.90.0-insider (Universal)
Commit: 26c4a07b47a2bd34480a5e4cba2c2384c590b039
Date: 2024-05-10T18:24:30.982Z
Electron: 29.3.1
ElectronBuildId: 9464424
Chromium: 122.0.6261.156
Node.js: 20.9.0
V8: 12.2.281.27-electron.0
OS: Darwin arm64 23.4.0

[mxschmitt]

Weird, was yesterday able to reproduce it consistently, my suspicion is that it was a Node.js bug, which is probably fixed in recent Node.js - waiting for our customer to try out recent Node.js.

[Makeshift]

I believe I've been encountering something similar for the past few days, where certain interactions between the VSCode debugger, Yarn and AWS-CDK causes a hang.

I created a reproduction repo here, but thankfully found a workaround in the form of switching to the nightly version of the debugger extension. I haven't dug much more into it, but hopefully this helps someone.

[mxschmitt]

I'll close it for now since we are not able to reproduce anymore. We did a few changes around debugging (cwd, which might have been related) @Makeshift, if you still experience issues, I recommend filing a separate bug, so we don't mix. Thanks!

[mxschmitt]

Just for further reference, the issue in our case was: We were passing a number value as an arg. This ended up in:

ERR [Extension Host] TypeError: o.includes is not a function
    at Roe (c:\Users\xxx\AppData\Local\Programs\Microsoft VS Code\resources\app\extensions\ms-vscode.js-debug\src\extension.js:117:346)
    at pp.launchProgram (c:\Users\xxx\AppData\Local\Programs\Microsoft VS Code\resources\app\extensions\ms-vscode.js-debug\src\extension.js:115:9563)
    at n (c:\Users\xxx\AppData\Local\Programs\Microsoft VS Code\resources\app\extensions\ms-vscode.js-debug\src\extension.js:115:4131)
    at processTicksAndRejections (node:internal/process/task_queues:95:5)
    at ap.launch (c:\Users\xxx\AppData\Local\Programs\Microsoft VS Code\resources\app\extensions\ms-vscode.js-debug\src\extension.js:113:31785)
    at jI.captureLaunch (c:\Users\xxx\AppData\Local\Programs\Microsoft VS Code\resources\app\extensions\ms-vscode.js-debug\src\extension.js:130:11414)
    at jI._launch (c:\Users\xxx\AppData\Local\Programs\Microsoft VS Code\resources\app\extensions\ms-vscode.js-debug\src\extension.js:130:11161)
    at async Promise.all (index 3)
    at jI._boot (c:\Users\xxx\AppData\Local\Programs\Microsoft VS Code\resources\app\extensions\ms-vscode.js-debug\src\extension.js:130:10285)
    at c:\Users\xxx\AppData\Local\Programs\Microsoft VS Code\resources\app\extensions\ms-vscode.js-debug\src\extension.js:130:9214
    at mu._onMessage (c:\Users\xxx\AppData\Local\Programs\Microsoft VS Code\resources\app\extensions\ms-vscode.js-debug\src\extension.js:47:4835)

here:

https://github.com/microsoft/vscode-js-debug/blob/f82c9eb479cc5344654931cf4b27c75790aff3ae/src/targets/node/subprocessProgramLauncher.ts#L144

Maybe we should validate that string[] gets passed? Since the types only accept string[] inside js-debug extension, but when using the VSCode API, its pretty loose, its any I think.

[connor4312]

js-debug currently does no validation of the launch configuration passed to it. User-authored configurations will get warning diagnostics if they have something invalid in their launch.json based on the JSON schema, for API usages consumers just have to make sure they're giving valid data 🙂

[connor4312]

This seems like it may have been https://github.com/nodejs/node/issues/50516 if the path contained multi-byte code points (see linked issue above)