Deno inspector closes socket before vscode can connect

Describe the bug Debugger only works once after reloading cache, Then exits with code 1 and next debug sessions don’t work until the command deno cache -r <file> is ran.

To Reproduce

1. Create a simple typescript file, let’s say Hi.ts with this code : console.log('Hi');
2. Set a breakpoint
3. Launch Debugger using F5 (Without a launch.json file), The breakpoint hits. Once you end debugging and expect the program to end, the debugger controls just stay there; and you have to press stop to end the session.
4. At the end of the session you’ll have an output similar to this one in console :

B:\Prog\Dev\Deno\deno.EXE run --unstable --inspect --allow-all .\Hi.ts
Hi
Hi.ts:1
Debugger listening on ws://127.0.0.1:9229/ws/9e5ecde2-ab9f-41bf-aede-e8194a78d3d4
Check file:///B:/Proj/DenoIssue/Hi.ts
Debugger session started.
Process exited with code 1

1. Try to launch the debugger again without making any changes to the code.
2. The debugger doesn’t work, VS Code debugging controls disappear and you’ll end up with just this line as your output :

B:\Prog\Dev\Deno\deno.EXE run --unstable --inspect --allow-all .\Hi.ts

1. Now run this command : deno cache -r Hi.ts to reload the cache.
2. Try to launch the debugger again, The same thing as step 3 happens, and the story continues !

Expected behavior At step 3, process is expected to exit (with code 0) after debugging is finished. At step 6, debugger is expected to work without the need to reload the cache.

Screenshots Step 3 : Debugger Working

Step 3 : End of Debugging, Program doesn’t exit

Step 4 : Process exiting with non-zero code after stopping the debugger using the controls’ stop button.

Step 6 : Trying to debug the same code again, results in unexpected behavior

Versions

VSCode :

• Version: 1.61.0 (system setup)
• Commit: ee8c7def80afc00dd6e593ef12f37756d8f504ea
• Date: 2021-10-07T18:13:09.652Z
• Electron: 13.5.1
• Chrome: 91.0.4472.164
• Node.js: 14.16.0
• V8: 9.1.269.39-electron.0
• OS: Windows_NT x64 10.0.19043

Deno :

• deno 1.14.3 (release, x86_64-pc-windows-msvc)
• v8 9.4.146.19
• typescript 4.4.2

Extension : 3.9.1

[kitsonk]

I think it is because the inspector drops before the connection before vscode can connect to it and express a breakpoint, so vscode fumbles a bit when trying to connect to the inspector that isn’t there anymore.

I believe the reason why the --reload fixes it in some cases is because the default inspect uses --unstable. When that occurs the configuration of the emit changes, which invalidates the previous emit, and then causes the re-re-load the code, which gives vscode enough time to connect to the inspector and set a break point.

Changing to --inspect-brk “fixes” the issue as well, though it would likely dump people into strange parts of code, and the reason we default to just --inspect.

I have opened denoland/deno#12417 to try to address it.

[KotlinIsland]

Deno is literally unusable until this is fixed.