Option to hide "Debugger attached" console log on connected debugger

[sebmck]

Is your feature request related to a problem? Please describe.

Our project Rome has a test runner. We spawn worker_threads to execute tests. We attach a debugger to each of them so we can collect stacktraces when tests timeout and have a blocked event loop. Right now, Node always outputs a "Debugger attached" message to stderr src/inspector_io.cc. This leads to console spam whenever a test worker is started. That isn't ideal for an implementation detail and looks like a bug to a user.

Describe the solution you'd like

A way to disable the "Debugger attached" message, possibly via an environment variable or CLI flag.

Describe alternatives you've considered

Previously we used forked child processes and so had a dedicated stderr where we could intercept and hide it. Unfortunately, it seems like there's no way to do that specifically with everything in the same process and that the log never happens in JS.

[aduh95]

FWIW, it's already possible to detach worker's standard IO:

$  node -e "new (require('worker_threads').Worker)('console.error(4)', {eval:true})"
4
$  node -e "new (require('worker_threads').Worker)('console.error(4)', {eval:true, stderr:true})"
$

[devsnek]

@sebmck are you starting the inspector via the require('inspector') api? I find it very annoying that starting the inspector programmatically prints stuff out.

[sebmck]

Sorry, I should have provided a repro snippet. stderr: true, stdout: true has no effect on how the "Debugger attached" log is written.

I'm using inspector.open(); in a worker thread, passing inspector.url() back to the main thread, and connecting to it with a websocket.

$ node --inspect-publish-uid=http worker.js
Debugger attached.

const {Worker} = require('worker_threads');
const crypto = require('crypto');
const http = require('http');
const net = require('net');

const worker = new Worker(
  "require('inspector').open(8888); require('worker_threads').parentPort.postMessage(require('inspector').url()); setInterval(() => {}, 1000);",
  {eval: true, stdout: true, stderr: true, stdin: true},
);

worker.on('message', (url) => {
  http.request({
    hostname: "127.0.0.1",
    port: 8888,
    path: "/" + url.split("/").pop(),
    method: "GET",
    headers: {
      Connection: "Upgrade",
      Upgrade: "websocket",
      "Sec-WebSocket-Key": "foobar",
      "Sec-WebSocket-Version": "13",
    },
  }).end();
});

[devsnek]

Not sure whether to call this a bug or a feature request, but it should definitely be fixed.

[nathanblair]

This would make working with vs code much nicer as well. I think there's probably some magic that could be done to redirect the stderr stream of this information to some null fd or something but a built-in flag would be 😍

[bnoordhuis]

I'd be okay with removing that specific message, I don't think it adds much value. Or are there are third-party tools using it as an eye catcher?

Here's a diff, feel free to steal and pull request to get the conversation going:

diff --git a/src/inspector_io.cc b/src/inspector_io.cc
index d3bd191121..9e5c9d281b 100644
--- a/src/inspector_io.cc
+++ b/src/inspector_io.cc
@@ -341,10 +341,7 @@ void InspectorIoDelegate::StartSession(int session_id,
   auto session = main_thread_->Connect(
       std::unique_ptr<InspectorSessionDelegate>(
           new IoSessionDelegate(request_queue_->handle(), session_id)), true);
-  if (session) {
-    sessions_[session_id] = std::move(session);
-    fprintf(stderr, "Debugger attached.\n");
-  }
+  if (session) sessions_[session_id] = std::move(session);
 }
 
 void InspectorIoDelegate::MessageReceived(int session_id,

[justingrant]

I just ran into this problem while trying to set up VSCode debugging of tests run by the the Test262 test harness used to test JS engines like V8. This test harness treats any console output as a test failure.

So it'd be great to have some way to hide these messages so that these tests won't have false-negative failures when run under the debugger.

[justingrant]

Note that I'd want to remove both the attaching ("Debugger attached.\n") and detaching ("Waiting for the debugger to disconnect...\n") messages.

[tot-rgo]

Was this feature ever implemented? Is there any activity regarding this issue? I'm getting a ton of these messages when debugging Vitest in VSCode.

[icetbr]

@tot-rgo My workaround, using a custom reporter that prints as last message

  process.stdout.write('\x1b[8m') // adds hide effect to text

and as first

  process.stdout.write('\x1b[0m') // reset effects

You could extend your favorite reporter from vitest, something like

export class MyReporter extends DotReporter {
  onWatcherRerun(files: string[], trigger?: string): void {
      process.stdout.write('\x1b[0m') // reset effects
      super.onWatcherRerun(files, trigger)
  }

  onFinished(files?: File[], errors?: unknown[]): void {
    super.onFinished(files, errors)
    process.stdout.write('\x1b[8m') // adds hide effect to text
  }

}

[marcusball]

This would be a really nice feature. The log lines are making it very annoying to run scripts while using an editor. I don't want to have to completely disable debugging to avoid this. An example of the kind of annoyance this is causing is this output:

Debugger listening on ws://127.0.0.1:41393/cb3f59d9-43ff-4b52-b523-166591241ec5
For help, see: https://nodejs.org/en/docs/inspector
Debugger attached.
Debugger listening on ws://127.0.0.1:36243/a2ccda17-b03c-4683-a990-a5eb09e34103
For help, see: https://nodejs.org/en/docs/inspector
Debugger attached.
Debugger listening on ws://127.0.0.1:39253/e79bfa47-7157-41c3-ba9b-2ff315732417
For help, see: https://nodejs.org/en/docs/inspector
Debugger listening on ws://127.0.0.1:43163/b1559b9f-ec26-4d86-a972-f5c52476a38b
For help, see: https://nodejs.org/en/docs/inspector
Debugger listening on ws://127.0.0.1:35771/5730ba6c-2648-4b97-b78d-2fbb4707b573
For help, see: https://nodejs.org/en/docs/inspector
Debugger listening on ws://127.0.0.1:35321/1c545b81-bbb8-4e40-b79e-e3c385a086c6
For help, see: https://nodejs.org/en/docs/inspector
Debugger listening on ws://127.0.0.1:43855/5aa32d4c-d009-4299-ad93-32fb91163ad9
For help, see: https://nodejs.org/en/docs/inspector
Debugger listening on ws://127.0.0.1:36287/25466ff3-1977-4049-a26e-05db0b8838f8
For help, see: https://nodejs.org/en/docs/inspector
Debugger listening on ws://127.0.0.1:40521/1e1d120f-37f7-4932-92a7-274ea9c162fb
For help, see: https://nodejs.org/en/docs/inspector
Debugger listening on ws://127.0.0.1:42083/f99d9fd1-0b23-4125-94b6-dc2a0ae7a639
For help, see: https://nodejs.org/en/docs/inspector
Debugger attached.
Debugger attached.
Debugger attached.
Debugger attached.
Debugger attached.
Debugger attached.
Debugger attached.
Debugger attached.
Debugger listening on ws://127.0.0.1:40775/b3d4f92f-0c8c-42e5-9249-7cab05d8b015
For help, see: https://nodejs.org/en/docs/inspector
Debugger attached.
Debugger listening on ws://127.0.0.1:39505/68d5e91e-738a-4b0a-b875-048d7fce2403
For help, see: https://nodejs.org/en/docs/inspector
Debugger attached.
Waiting for the debugger to disconnect...
Waiting for the debugger to disconnect...
Debugger listening on ws://127.0.0.1:46283/93bb1be9-4df7-48b1-a651-b03a626cf42b
For help, see: https://nodejs.org/en/docs/inspector
Debugger attached.
Debugger listening on ws://127.0.0.1:37663/30931978-0a2a-475d-91d1-fc9e8b477a2b
For help, see: https://nodejs.org/en/docs/inspector
Debugger attached.
Waiting for the debugger to disconnect...
Waiting for the debugger to disconnect...
Debugger listening on ws://127.0.0.1:41869/8772549d-421b-4304-821d-b79309b4f551
For help, see: https://nodejs.org/en/docs/inspector
Debugger attached.
Debugger listening on ws://127.0.0.1:37829/f6c44182-1953-4759-b5bd-530531fb0875
For help, see: https://nodejs.org/en/docs/inspector
Debugger attached.
Waiting for the debugger to disconnect...
Waiting for the debugger to disconnect...
Debugger listening on ws://127.0.0.1:43063/0d4d276b-4764-4f21-92d5-6727fe87fd96
For help, see: https://nodejs.org/en/docs/inspector
Debugger attached.
Debugger listening on ws://127.0.0.1:37939/3d42cc7c-1c51-45dd-89fc-f6e83cf5ecbf
For help, see: https://nodejs.org/en/docs/inspector
Debugger attached.
Waiting for the debugger to disconnect...
Waiting for the debugger to disconnect...
Debugger listening on ws://127.0.0.1:36797/d2fb0285-b188-4b67-be71-3f959076eeac
For help, see: https://nodejs.org/en/docs/inspector
Debugger attached.
Debugger listening on ws://127.0.0.1:38951/c4c59aaf-2be6-46b1-ab58-64faa2aeb330
For help, see: https://nodejs.org/en/docs/inspector
Debugger attached.
Waiting for the debugger to disconnect...
Waiting for the debugger to disconnect...
Debugger listening on ws://127.0.0.1:40257/65e85756-4cda-4470-a69f-ffef30c0616d
For help, see: https://nodejs.org/en/docs/inspector
Debugger attached.
Debugger listening on ws://127.0.0.1:41221/f9b7f52a-ca15-4db2-bf96-c33fef333875
For help, see: https://nodejs.org/en/docs/inspector
Debugger attached.
Waiting for the debugger to disconnect...
Waiting for the debugger to disconnect...
Debugger listening on ws://127.0.0.1:45693/5a73f4ee-b341-4ead-9353-a23ccb13cf95
For help, see: https://nodejs.org/en/docs/inspector
Debugger attached.
Debugger listening on ws://127.0.0.1:42709/e02e2f23-b49d-4b10-8b63-68a27b242296
For help, see: https://nodejs.org/en/docs/inspector
Debugger attached.
Waiting for the debugger to disconnect...
Waiting for the debugger to disconnect...
[ACTUAL SCRIPT OUTPUT]
Waiting for the debugger to disconnect...
Waiting for the debugger to disconnect...
Waiting for the debugger to disconnect...
Waiting for the debugger to disconnect...
Waiting for the debugger to disconnect...
Waiting for the debugger to disconnect...
Waiting for the debugger to disconnect...
Waiting for the debugger to disconnect...
Waiting for the debugger to disconnect...
Waiting for the debugger to disconnect...

This is 96 lines of debugger logs for 1 line of script output buried in the middle of it. It's obviously an extreme case because it's some dev tools spawning additional processes, but past a certain point it's no longer helpful output at all, and having something like an environment variable to suppress it would be extremely helpful.