Repository navigation
Option to hide "Debugger attached" console log on connected debugger #34799
Description
Activity
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})" $
Sorry, I should have provided a repro snippet.
stderr: true, stdout: truehas no effect on how the "Debugger attached" log is written.I'm using
inspector.open();in a worker thread, passinginspector.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(); });Not sure whether to call this a bug or a feature request, but it should definitely be fixed.
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 😍
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,
Reacted by Mike Kormendy and Justin GrantI 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.
Reacted by Rob HoganNote that I'd want to remove both the attaching (
"Debugger attached.\n") and detaching ("Waiting for the debugger to disconnect...\n") messages.Reacted by electrovir and BernardWas this feature ever implemented? Is there any activity regarding this issue? I'm getting a ton of these messages when debugging Vitest in VSCode.
@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 }
}
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.
Reacted by Jiyan Akgül and Cefn HoileThis 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.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.
Is your feature request related to a problem? Please describe.
Our project Rome has a test runner. We spawn
worker_threadsto 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 stderrsrc/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
stderrwhere 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.