Issues with launching debug

[kitsonk]

@kitsonk Certainly; no problem.

It is still not working for me. I am still experiencing the same result as in my previous comment: #12 (comment)

Here is some additional information:

When I have no .vscode/launch.json config and simply press F5 (run the debugger), I am presented with a list of choices. I choose the one named "Deno: Run". After waiting several seconds, I receive this error dialog:

If I then create a custom launch config file, I can get further in the debug process, but only to the point described in my previous comment.

For comparison, here are multiple debug configs, commented to explain their sources:

{
  "version": "0.2.0",
  "configurations": [
    {
      "name": "Deno (from extension)", // generated by using "Add configuration... > Deno: Run"
      "type": "pwa-node",
      "request": "launch",
      "program": "${workspaceFolder}/main.ts", // it seems "main.ts" is assumed, but the file might not exist
      "cwd": "${workspaceFolder}",
      "runtimeExecutable": "deno",
      "runtimeArgs": [
        "run",
        "--inspect=127.0.0.1:9229",
        "--allow-all" // unsafe default
      ],
      "attachSimplePort": 9229
    },
    {
      "name": "Deno (from manual)", // from https://deno.land/manual@v1.8.3/getting_started/debugging_your_code#vscode
      "type": "pwa-node",
      "request": "launch",
      "cwd": "${workspaceFolder}",
      "runtimeExecutable": "deno",
      "runtimeArgs": ["run", "--inspect-brk", "-A", "${file}"], // unsafe default permissions
      "attachSimplePort": 9229
    },
    {
      "name": "Deno (custom)", // manually created
      "type": "pwa-node",
      "request": "launch",
      "program": "${file}",
      "cwd": "${workspaceFolder}",
      "runtimeExecutable": "deno",
      "runtimeArgs": [
        "run",
        "--inspect-brk"
      ],
      "attachSimplePort": 9229
    }
  ]
}

I ran this test again today on WSL, but haven't tested again on macOS yet.

Here is a zip file containing the workspace folder used when I did this test before posting this comment:

debug-example.zip

Env:

$ deno --version
deno 1.8.3 (release, x86_64-unknown-linux-gnu)
v8 9.0.257.3
typescript 4.2.2

$ code --version
1.55.0
c185983a683d14c396952dd432459097bc7f757f
x64

$ code --list-extensions --show-versions | grep "deno"
denoland.vscode-deno@3.2.0

Originally posted by @jsejcksn in #12 (comment)

[jsejcksn]

Thanks for moving this @kitsonk

[brandonkal]

The debug error is about as useless to me too.
It appears deno exits 1 too fast for it to recognize there is a breakpoint. --inspect-brk seems to help at least vs --inspect.

[zandaqo]

So, am I correct to assume that debugging doesn't work with the latest VSCode/Deno/vscode_deno?

I am giving VSCode a try since WebStorm's support for Deno is nigh non-existent. I've installed everything just now, and I am getting a similar error:

Here is my launch config:

{
    "version": "0.2.0",
    "configurations": [
      {
          "name": "Deno Debug Current",
          "type": "pwa-node",
          "request": "launch",
          "program": "${file}",
          "cwd": "${workspaceFolder}",
          "runtimeExecutable": "deno",
          "runtimeArgs": ["run", "--inspect", "-A"],
          "outputCapture": "std",
          "attachSimplePort": 9229
      }
    ]
}

Upon running it outputs the following, waits for some time and the throws the above depicted error.

C:\Users\arthur\.deno\bin\deno.exe run --inspect -A .\index_test.ts
Debugger listening on ws://127.0.0.1:9229/ws/b2b4e7ee-4f0e-4905-b7cd-c50cce81eeb0

[zandaqo]

Tried this with canary and it seems to work:

> deno --version
deno 1.9.2+688557e (canary, x86_64-pc-windows-msvc)
v8 9.1.269.5
typescript 4.2.2

[edit] and it's stopped working again with same error after updating to the next canary version.

> deno --version
deno 1.9.2+d806dc0 (canary, x86_64-pc-windows-msvc)
v8 9.1.269.5
typescript 4.2.2```

[zandaqo]

The error persists in the latest versions:

> deno --version
deno 1.10.1 (release, x86_64-pc-windows-msvc)
v8 9.1.269.27
typescript 4.2.2

> code --version
1.56.0
cfa2e218100323074ac1948c885448fdf4de2a7f
x64

And the plugin version is 3.4.

Setting internalDebug flag doesn't give any more info:

{
    "deno.enable": true,
    "deno.lint": true,
    "deno.unstable": true,
    "deno.internalDebug": true
}

This is rather annoying, any pointers on how to go debugging this? I don't have much experience with VSCode so I'm at a loss here.

[sapradhan]

The debug error is about as useless to me too.
It appears deno exits 1 too fast for it to recognize there is a breakpoint. --inspect-brk seems to help at least vs --inspect.

I can confirm --inspect-brk works for me on Deno 1.11.2.

My observation was that --inspect worked a few times then I started getting Could not connect to debug target (possibly after forcefully terminating debug session by pressing the stop button)

[jradxl]

Glad others are having same problem as me, as per my issue
#458

[jamesej]

I am having this same issue, I have to use --inspect-brk to get debugging to work at all, and then with this flag, I get the error message Could not connect to debug target mentioned.

This is however intermittent for me, it generally occurs on the first run after making a source code change. The last line in the Terminal is:
Debugger listening on ws://127.0.0.1:9229/ws/
and I have no prompt. If I get back to a prompt with CTRL+C, and start debugging again then it usually works on the second run.

This strongly suggests a race condition where the debugger tries to connect to the debug target before it has come up. This is an everyday annoyance for me and probably many or most Deno users on VS code, it gives the impression that Deno is a beta product, and it has not been fixed in many updates. I'd suggest prioritising this.

[daffodilistic]

Confirming it's also failing to attach on Windows 10 with --inspect:

> deno --version
deno 1.13.1 (release, x86_64-pc-windows-msvc)
v8 9.3.345.11
typescript 4.3.5

> code --version
1.59.0
379476f0e13988d90fab105c5c19e7abc8b1dea8
x64

Using --inspect-brk works and I can step through the sample hello-world.ts code, but it seems that either the debugger doesn't detach itself automatically, or deno doesn't terminate when the program finishes execution.

[johnmw]

Just confirming its also happening to me on OS X, VS Code 1.59.1, Deno for VSC 3.8.1 and Deno 1.13.2.

Changing --inspect to --inspect-brk in launch.json allows debugging (and, if needed, updating the default "program": "main.ts" start file).

And a quick fix to make life more pleasant for us noobs would be to update the auto generated launch file in the Deno VS Code plugin as it creates the initial "Deno: Run" config with the --inspect flag.

(Precise error, in case someone is searching is:)

Error processing launch: Error: Could not connect to debug target at http://127.0.0.1:9229: Could not find any debuggable target
at Object.retryGetNodeEndpoint (/Applications/Visual Studio Code.app/Contents/Resources/app/extensions/ms-vscode.js-debug/src/extension.js:2:1299673)
at runMicrotasks (<anonymous>)
at processTicksAndRejections (internal/process/task_queues.js:93:5)
at async t (/Applications/Visual Studio Code.app/Contents/Resources/app/extensions/ms-vscode.js-debug/src/extension.js:2:1334021)
at async P.launch (/Applications/Visual Studio Code.app/Contents/Resources/app/extensions/ms-vscode.js-debug/src/extension.js:2:1338708)
at async t.Binder.captureLaunch (/Applications/Visual Studio Code.app/Contents/Resources/app/extensions/ms-vscode.js-debug/src/extension.js:2:1131804)
at async t.Binder._launch (/Applications/Visual Studio Code.app/Contents/Resources/app/extensions/ms-vscode.js-debug/src/extension.js:2:1131349)
at async Promise.all (index 3)
at async t.Binder._boot (/Applications/Visual Studio Code.app/Contents/Resources/app/extensions/ms-vscode.js-debug/src/extension.js:2:1130401)
at async t.default._onMessage (/Applications/Visual Studio Code.app/Contents/Resources/app/extensions/ms-vscode.js-debug/src/extension.js:2:1222624)

[kitsonk]

There are several different issues occurring here.

We didn't have a very intelligent "default" debug configuration, nor did the code that created a launch.json work correctly in a lot of environments/situations. #513 should have fixed that.

We changed the default from --inspect-brk to --inspect because some people felt it better default, but then in that case, if you code doesn't await for a request, or you don't have a breakpoint test, it just exits. I will try to improve the documentation around debugging to make these clear.

For now I am going to close this issue, and once #513 is released, if there are still issues, I would encourage people to open a new issue so it can be investigated, as this issue has several root causes going on.