Calling inspector.open() if the inspector is already available makes inspector.url() give a bad address

[connor4312]

• Version: v12.14.1
• Platform: win32
• Subsystem: Inspector

What steps will reproduce the bug?

1. Create a script foo.js with:

   const inspector = require('inspector');
   console.log(inspector.url());
   inspector.open(0, undefined, false);
   console.log(inspector.url());

2. Run node foo.js ✔️

   undefined
   Debugger listening on ws://127.0.0.1:37569/25b0bbd1-1b2d-45ab-bcb5-2e509196df2a
   For help, see: https://nodejs.org/en/docs/inspector
   ws://127.0.0.1:37569/25b0bbd1-1b2d-45ab-bcb5-2e509196df2a
   

3. Run node --inspect foo.js ❌

   Debugger listening on ws://127.0.0.1:9229/f72b422b-dde6-4d57-a507-86f4b7faf919
   For help, see: https://nodejs.org/en/docs/inspector
   ws://127.0.0.1:9229/f72b422b-dde6-4d57-a507-86f4b7faf919
   ws://127.0.0.1:0/f72b422b-dde6-4d57-a507-86f4b7faf919
   

How often does it reproduce? Is there a required condition?

100%

What do you see instead? / What is the expected behavior?

It seems like calling inspect() again will silently "overwrite" the existing run with an unresolved port 0. I would expect any of the following as 'good' behavior:

• An error is thrown (if we can't open the inspector on the new port)
• The port is changed to the new address
• or the inspector.url() is unaffected (no-op)

Additional information

Ref: microsoft/vscode#95128

[joyeecheung]

I guess in this case, throwing an error warning that the inspector needs to be closed before being opened again should make more sense. However this does break https://github.com/nodejs/node/blame/master/test/sequential/test-inspector-open.js @sam-github is there a particular reason inspector.open() is a no-op (well, not quite, this currently resets the port and host stored in Environment, still nothing meaningful would be done) when the inspector is already active (even though possibly with a different address)?