Actions launched from a server ready action in compound launch configs don't honor the stopAll flag

[samamorgan]

Does this issue occur when all extensions are disabled?: Yes

• VS Code Version: 1.71.2
• OS Version: Windows_NT x64 10.0.19044

Steps to Reproduce:

1. Create a compound launch configuration with "stopAll": true where one of the configs includes serverReadyAction
2. Launch a debug session with this configuration
3. Press the stop button
   • Expected: All sessions stop
   • Actual: The sessions enumerated in the compound configurations stop, but the session launched under serverReadyAction does not. The user must click stop twice for all sessions to cease.

My launch config:

{
  "version": "0.2.0",
  "compounds": [
    {
      "name": "Debug app",
      "configurations": ["Django", "Vite"],
      "stopAll": true
    }
  ],
  "configurations": [
    {
      "name": "Django",
      "type": "python",
      "request": "launch",
      "program": "${workspaceFolder}/manage.py",
      "args": ["runserver"],
      "django": true,
      "justMyCode": true,
      "presentation": { "hidden": true },
      "cwd": "${workspaceFolder}",
      "serverReadyAction": {
        "pattern": ".*(https?:\\/\\/\\S+:[0-9]+\\/?).*",
        "uriFormat": "%s",
        "action": "debugWithChrome"
      }
    },
    {
      "name": "Vite",
      "type": "node",
      "request": "launch",
      "runtimeExecutable": "npm",
      "runtimeArgs": ["run", "dev"],
      "presentation": { "hidden": true },
      "cwd": "${workspaceFolder}"
    }
  ]
}

Video demonstrating the behavior:

sampleapp.-.Visual.Studio.Code.2022-10-09.09-14-25.mp4

[VSCodeTriageBot]

Thanks for creating this issue! It looks like you may be using an old version of VS Code, the latest stable release is 1.72.0. Please try upgrading to the latest version and checking whether this issue remains.

Happy Coding!

[samamorgan]

I just upgraded to 1.72.0 and the issue is unchanged.

[roblourens]

"stopAll" isn't really related here - normally, there is no relationship between the server and browser debug session. But it might make sense to stop the browser session when the server session is stopped.

We could try starting the browser session as a child of the server session, I don't think a child is automatically stopped when a parent is stopped though. The debug-server-ready extension could watch for the server session to end, and then manually stop the browser session. There might be some valid case when you want to keep debugging the browser after the server has terminated, so there could be an option for this too.

Thoughts @connor4312?

[connor4312]

I don't think having a child session is a good thing, but we could have the debug-server-ready extension monitor the state as you suggest. I think that would be fine.

[samamorgan]

Whatever you folks think is best works for me. I've sidestepped the issue for now by just adding a third debug config that launches a browser, but it isn't quite as slick as using serverReadyAction since the browser launches and waits. I also can't parse out the URL this way like serverReadyAction, I have to hardcode it, which isn't ideal for long-term maintenance.

[babakks]

@roblourens @connor4312 Do you think introducing a new property in serverReadyAction is a good idea? something like killOnServerStop:

{
  "serverReadyAction": {
    "pattern": ".*(https?:\\/\\/\\S+:[0-9]+\\/?).*",
    "uriFormat": "%s",
    "action": "debugWithChrome",
    "killOnServerStop": true
  }
}

[roblourens]

That would make sense to me. I don't have time to work on it right now but would take a PR

[babakks]

@roblourens I'll submit a PR.

[babakks]

@roblourens Just submitted the PR for you to check it whenever you had time.