[Regression] A new CMake Debugger instance will generate after running "CMake: Configure with CMake Debugger" for the second time

[Amy-Li03]

Brief Issue Summary

Environment:

VS Code 1.96.2 + CMake Tools v1.20.34 (pre-release)

More info:

1. This issue doesn't repro on v1.19.16(pre-release), it starts repro from v1.19.17(pre-release) to latest version v1.20.34(pre-release), so it is a regression issue
2. This issue reproduces on Windows, Linux, and Mac platforms

Repro steps:

1. Unzip the project and open it with vscode.CMakeProject1.zip
2. Set a breakpoint on line12: "project("CMakeProject1")"
3. Open the command palette (F1 or Ctrl+Shift+P)
4. Enter and select the command “CMake: Configure with CMake Debugger”
5. Open the command palette (F1 or Ctrl+Shift+P)
6. Enter and select the command “CMake: Configure with CMake Debugger” once more
7. Observe the CMake Debugger instance in Call Stack window

Actual result:

After step4, the breakpoint will be hit. - correct
After step7, a new CMake Debugger instance will generate, and we cannot stop it. - incorrect

Expected result:

After step4, the breakpoint will be hit.
After step7, no new CMake Debugger instance generate.

CMake Tools Diagnostics

Debug Log

Additional Information

No response

[gcampbell-msft]

Did some initial investigation.

The issue here is stemming from the fact that we are using vscode.debug.startDebugging as the entry point for the commands to configure with CMake debugger. This works as expected in nearly all cases except for this one.

The reason it doesn't work as expected in this one, is because we return early out of the configure methods due to already being in a configure. When we return early, we don't resolved the debuggerReady promise, and therefore we end up spinning in the DebugAdapterNamedPipeServerDescriptorFactory createDebugAdapterDescriptor waiting for the debugAdapterDescriptor.

We will likely need a slight refactor, or we need to be okay with adding another promise that we can wait with Promise.race, and when the cancelled one finishes first, it will error out with a popup saying that we weren't able to connect to it.

The simplest fix is likely to deal with the fact that there will be a modal popup, since this is hopefully a rare scenario, and when it happens, it would be confusing if users didn't get an obvious pop-up telling them why we weren't able to configure. This is my suggestion.