Skip to content

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

Closed as not planned
Closed as not planned
Option to hide "Debugger attached" console log on connected debugger#34799
Labels
inspectorIssues and PRs related to the V8 inspector protocol.staleIssues and PRs marked stale due to inactivity and scheduled for automatic closure.

Description

@sebmck
sebmck
opened on Aug 16, 2020

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.

Activity

  1. aduh95 commented on Aug 16, 2020

    @aduh95
    aduh95
    on Aug 16, 2020
    Contributor

    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})"
$
  2. devsnek
    added
    inspectorIssues and PRs related to the V8 inspector protocol.
    on Aug 16, 2020

  3. devsnek commented on Aug 16, 2020

    @devsnek
    devsnek
    on Aug 16, 2020
    Member

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

  4. sebmck commented on Aug 16, 2020

    @sebmck
    sebmck
    on Aug 16, 2020
    Author

    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();
});

  5. devsnek commented on Aug 16, 2020

    @devsnek
    devsnek
    on Aug 16, 2020
    Member

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

  6. nathanblair commented on Aug 17, 2020

    @nathanblair
    nathanblair
    on Aug 17, 2020

    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 😍

  7. bnoordhuis commented on Aug 17, 2020

    @bnoordhuis
    bnoordhuis
    on Aug 17, 2020
    Member

    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,

  8. justingrant commented on Sep 9, 2021

    @justingrant
    justingrant
    on Sep 9, 2021

    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.

  9. justingrant commented on Sep 9, 2021

    @justingrant
    justingrant
    on Sep 9, 2021

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

  10. tot-rgo commented on May 3, 2025

    @tot-rgo
    tot-rgo
    on May 3, 2025

    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.

  11. icetbr commented on May 9, 2025

    @icetbr
    icetbr
    on May 9, 2025

    @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
  }

    }

  12. marcusball commented on May 21, 2025

    @marcusball
    marcusball
    on May 21, 2025

    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.

  13. github-actions commented on Jun 27, 2026

    @github-actions
    github-actionsbot
    on Jun 27, 2026 – with GitHub Actions
    Contributor

    This issue has been marked as stale due to 210 days of inactivity.
    It will be automatically closed in 30 days if no further activity occurs. If this is still relevant, please leave a comment or update it to keep it open.

  14. github-actions
    added
    staleIssues and PRs marked stale due to inactivity and scheduled for automatic closure.
    on Jun 27, 2026

  15. github-actions commented on Jul 28, 2026

    @github-actions
    github-actionsbot
    on Jul 28, 2026 – with GitHub Actions
    Contributor

    This issue has been automatically closed after 30 days of inactivity following its stale status (no activity for a total of 120 days).
    If this is still relevant, feel free to reopen it or leave a comment with additional details so we can continue the discussion.

  16. github-actions
    closed this as not plannedon Jul 28, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    inspectorIssues and PRs related to the V8 inspector protocol.staleIssues and PRs marked stale due to inactivity and scheduled for automatic closure.

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions