Extension hangs if debugger is detached during a breakpoint pause

[xaviergmail]

Describe the bug

After running a test in debug mode

Reproduction

Can't really reproduce on StackBlitz. I can reproduce it on the basic example. The only modification is my vite.config.ts specifies this:

  test: {
    include: [
      "app/**/*.test.server.ts",
    ],

1. Debug a test with a breakpoint
   

2. Once paused on the breakpoint, hit either "Disconnect" or "Stop" from the debug panel
   

3. Notice the test keeps the spinning running icon:
   

4. Right click the same test -> Debug test, this works and it can be re-run

5. Right click -> Run test (NOT debug) (or run test from test explorer view)
   

6. Notice it never runs
   

7. Right click the same test -> Debug test, this no longer works either and they just keep queuing up

This also seems to happen if the test being debugged fails.

I am unable to run any other test using the regular run config after that without reloading the editor window.

vitest extension logs

[INFO 12:54:29 AM] [Vitest] Extension is activated because Vitest is installed or there is a Vite/Vitest config file in the workspace.
[INFO 12:54:29 AM] [API] Running Vitest: v1.4.0 (/Volumes/projects/modular-bundles/extensions/modular-bundles/vite.config.js), v1.4.0 (/Volumes/projects/modular-bundles/vite.config.ts)
[INFO 12:54:31 AM] [API] Vitest process 79597 created
[INFO 12:54:34 AM] Running 1 file(s) with name pattern: ^\s?findMigrations finds all files$
[Worker] Debugger listening on ws://127.0.0.1:9229/347ba504-6379-4364-99d0-40b58524e7e8
For help, see: https://nodejs.org/en/docs/inspector
[Worker] Debugger attached.
[INFO 12:54:38 AM] [DEBUG] Debugging started
[INFO 12:54:38 AM] Running 1 file(s) with name pattern: ^\s?findMigrations finds all files$
[INFO 12:54:39 AM] Running 1 file(s) with name pattern: ^\s?findMigrations finds all files$
[Worker] Debugger ending on ws://127.0.0.1:9229/347ba504-6379-4364-99d0-40b58524e7e8
For help, see: https://nodejs.org/en/docs/inspector
[INFO 12:57:04 AM] Running 1 file(s) with name pattern: ^\s?findMigrations finds all files$
[INFO 12:57:04 AM] [API] Running Vitest: v1.4.0 (/Volumes/projects/modular-bundles/extensions/modular-bundles/vite.config.js), v1.4.0 (/Volumes/projects/modular-bundles/vite.config.ts)
[INFO 12:57:05 AM] [API] Vitest process 80839 created
[Worker] Debugger listening on ws://127.0.0.1:9229/2faac4d4-5ac3-4cdd-ba0d-3766f4a55a6f
For help, see: https://nodejs.org/en/docs/inspector
[Worker] Debugger attached.
[INFO 12:57:19 AM] [DEBUG] Debugging started
[INFO 12:57:19 AM] Running 1 file(s) with name pattern: ^\s?findMigrations finds all files$
[INFO 12:57:20 AM] Running 1 file(s) with name pattern: ^\s?findMigrations finds all files$
[Worker] Debugger ending on ws://127.0.0.1:9229/2faac4d4-5ac3-4cdd-ba0d-3766f4a55a6f
For help, see: https://nodejs.org/en/docs/inspector
[INFO 12:57:26 AM] Running 1 file(s) with name pattern: ^\s?findMigrations finds all files$
[Worker] Debugger listening on ws://127.0.0.1:9229/ad9d6116-c4a3-4f95-af6b-38c7f43a1f85
For help, see: https://nodejs.org/en/docs/inspector
[Worker] Debugger attached.
[INFO 12:57:43 AM] [DEBUG] Debugging started
[INFO 12:57:44 AM] Running 1 file(s) with name pattern: ^\s?findMigrations finds all files$
[INFO 12:57:44 AM] Running 1 file(s) with name pattern: ^\s?findMigrations finds all files$
[Worker] Debugger ending on ws://127.0.0.1:9229/ad9d6116-c4a3-4f95-af6b-38c7f43a1f85
For help, see: https://nodejs.org/en/docs/inspector
[Error 1:00:10 AM] [API] [Error Error] Channel closed
Error: Channel closed
at new NodeError (node:internal/errors:405:5)
at ChildProcess.send (node:internal/child_process:740:16)
at post (/Users/xavier/.vscode/extensions/vitest.explorer-0.5.9/dist/extension.js:3:2594)
at /Users/xavier/.vscode/extensions/vitest.explorer-0.5.9/dist/extension.js:3:1068
at new Promise ()
at Proxy.b (/Users/xavier/.vscode/extensions/vitest.explorer-0.5.9/dist/extension.js:3:823)

System Info

System:
    OS: macOS 14.1.1
    CPU: (12) arm64 Apple M2 Pro
    Memory: 92.25 MB / 16.00 GB
    Shell: 3.7.0 - /opt/homebrew/bin/fish
  Binaries:
    Node: 18.19.0 - ~/.asdf/installs/nodejs/18.19.0/bin/node
    Yarn: 1.22.21 - /Volumes/projects/modular-bundles/node_modules/.bin/yarn
    npm: 9.9.3 - /Volumes/projects/modular-bundles/node_modules/.bin/npm
  IDEs:
    VSCode: 1.87.2 - /usr/local/bin/code
    Vim: 9.0 - /usr/bin/vim
    Xcode: /undefined - /usr/bin/xcodebuild
  Browsers:
    Chrome: 123.0.6312.59
    Safari: 17.1

### Used Package Manager

yarn

### Validations

- [X] Follow our [Code of Conduct](https://github.com/vitest-dev/vscode/blob/main/CODE_OF_CONDUCT.md)
- [X] Read the [Contributing Guidelines](https://github.com/vitest-dev/vscode/blob/main/CONTRIBUTING.md).
- [X] Read the [docs](https://vitest.dev/guide/).
- [X] Check that there isn't [already an issue](https://github.com/vitest-dev/vscode/issues) that reports the same bug to avoid creating a duplicate.
- [X] Check that this is a concrete bug. For Q&A open a [GitHub Discussion](https://github.com/vitest-dev/vscode/discussions) or join our [Discord Chat Server](https://chat.vitest.dev).
- [X] The provided reproduction is a [minimal reproducible example](https://stackoverflow.com/help/minimal-reproducible-example) of the bug.

[ffMathy]

Which version of the extension are you using?

[ffMathy]

This no longer happens for me.

[sheremet-va]

This happens for me. Detaching a debugger during a breakpoint pause causes the extension to hang.

[sheremet-va]

The debugger works great now with #334, but we have a problem with "Restart" button.

@connor4312 do you know if it's possible to do an action before the debugger attaches itself when "Restart" button is clicked? I need to stop the previous inspector session before the new one attaches, and I wasn't able to find a solution using pwa-node:attach. I found a hidden preRestartTask option, but it's called too late - the new debug session is already attached by the time it's called.

I am experimenting in this PR: #334
You can reproduce this behavior like this:

1. Clone repo, install dependencies, run pnpm run compile
2. In the debug section click on "Run Extension Basic Example"
3. Put "debugger" statement somewhere in add.test.ts file
4. Click on debug icon for "add.test.ts" test item
5. Click on "Restart" - this will close the debugger because the inspector is closed after the session reattaches itself - in this situation, I want to wait until the test has finished running, and then attach the new session

If someone can help me out here, that would be great. If something needs to be done on Vitest's side for this to work, this is also fine.

[ffMathy]

For me to be able to look at this a bit maybe over the weekend, I need to understand: How did this work before the rewrite of the extension, and why? Or maybe it didn't?

[sheremet-va]

For me to be able to look at this a bit maybe over the weekend, I need to understand: How did this work before the rewrite of the extension, and why? Or maybe it didn't?

Before the rewrite, the extension was using pwa-node:launch debug configuration to spawn a new Vitest process. We now have an integration in Vitest to open an inspector in the process where the test is running.

[ffMathy]

And the original issue description, is that for the new extension or the old, released version?

[sheremet-va]

And the original issue description, is that for the new extension or the old, released version?

The original issue is about the pre-release version as you can see in the screenshot tests are rendered as a test tree which was not supported in the 0.4.0 (they were rendered as a list).

[ffMathy]

And the original issue description, is that for the new extension or the old, released version?

The original issue is about the pre-release version as you can see in the screenshot tests are rendered as a test tree which was not supported in the 0.4.0 (they were rendered as a list).

Aha.

I can't help but think we should maybe (for now, temporarily) make the debug functionality as it was in the old version (if possible).

Just to get to feature completion and get all of this unrealized great value out.

And then get the new method fixed afterwards.

What are your thoughts on this?

[sheremet-va]

I am going to release the rewritten debugger this week anyway. The only thing that doesn't work is "Restart" button, but you can always detach and start a new debug session.

I specifically asked @connor4312 because he was working on the JS debugger in vscode and maybe has some insights on this specific problem, but it doesn't block release. The only thing that was blocking release was Vitest 1.5.0 which I published yesterday.

[ffMathy]

Ah that's awesome! 😍

[connor4312]

do you know if it's possible to do an action before the debugger attaches itself when "Restart" button is clicked?

Playwright asked about the same thing for the same scenario in their tests. I think I started working on a branch locally at one point but never finished it... tracked here microsoft/vscode#210304

[sheremet-va]

do you know if it's possible to do an action before the debugger attaches itself when "Restart" button is clicked?

Playwright asked about the same thing for the same scenario in their tests. I think I started working on a branch locally at one point but never finished it... tracked here microsoft/vscode#210304

Thank you for looking into this 🙏🏻