-
Notifications
You must be signed in to change notification settings - Fork 335
Description
Describe the bug
(Note sure if bug or feature request is most appropriate, this might be a somewhat special case!)
wskdebug is a debugging tool for Apache Openwhisk (a serverless platform), which starts a container with a nodejs process inside that will have the actual debug port to which the VS Code debugger should connect. I am using this in VS Code as runtimeExecutable and have been intercepting the --inspect-brk=NNNN argument that was set by the previous debugger to use this port on the container that gets started. VS Code then did connect to the container, which was great.
However, it seems the new debugger uses a different mechanism. Apparently it sets NODE_OPTIONS with a --require that loads a JS file into the node process that apparently sets up the debugging from "inside" the process.
The problem is that now it debugs the wskdebug "intermediary" and not the target container.
Is there a way in the new debugger I can disable that and just get hold off the port number (which VS code randomly chooses, i.e. in case there are multiple debug sessions going on)?
See also apache/openwhisk-wskdebug#74
On a related note, the new debugger seems to kill the process at the end immediately (SIGKILL style). The previous debugger sent a SIGTERM so that the process had a chance to cleanup and properly exit. In wskdebug case this is used to stop the docker container amongst other things. With the new debugger this is no longer possible and thus the container with the open debug port is left behind, so that the next run usually fails with "debug port already in use". This is also an artifact of the above issue since always the same default debug port (9229) is picked now since --inspect-brk=NNNN with a unique port NNNN is missing.
To Reproduce
Steps to reproduce the behavior:
- Run launch config with
wskdebugas described here - Notice debugger connects to
wskdebugitself, but not the container it starts - Cannot hit any breakpoints since it's debugging the wrong process
Log File
VS Code Version: 1.47.1