microsoft/vscode-dapr

daprd-down postDebugTask fails to kill daprd process

asalvi0 opened this issue · 4 comments

Does this occur consistently? No
Repro steps:

  1. Create launch.json as follows:
{
    "version": "0.2.0",
    "configurations": [
        {
            "type": "go",
            "request": "launch",
            "name": "Go with Dapr",
            "mode": "debug",
            "program": "${workspaceFolder}\\cmd\\hnhandler",
            "console": "integratedTerminal",
            "preLaunchTask": "dapr-debug",
            "postDebugTask": "daprd-down",
        }
    ]
}
  1. Create tasks.json as follows:
{
   "version": "2.0.0",
   "tasks": [
       {
           "type": "dapr",
           "label": "dapr-debug",
           "appId": "hnhandler",
           "appProtocol": "grpc",
           "appPort": 5000,
           "componentsPath": "dapr/components",
           "presentation": {
               "showReuseMessage": false,
               "clear": true,
               "close": true,
               "focus": true
          }
       },
       {
           "type": "daprd-down",
           "label": "daprd-down",
           "appId": "hnhandler",
           "presentation": {
               "showReuseMessage": false,
               "clear": true,
               "close": true
          }
       }
   ]
}
  1. Stop the debugger and the dapr and daprd processes will continue running. The following error message is displayed:
    image

Action: vscode-dapr.tasks.dapr-down
Error type: ESRCH
Error Message: kill ESRCH

Version: 0.5.0
OS: win32
OS Release: 10.0.19043
Product: Visual Studio Code
Product Version: 1.63.0
Language: en

Call Stack
process.kill per_thread.js:200:13
extension.js:2:1496054extension.js:2:1496054
DaprdDownTaskProvider.<anonymous> extension.js:2:1496034
fulfilled extension.js:2:1495316
processTicksAndRejections task_queues.js:93:5

OS: Win10
Build Version: 20220108.1

Repro Steps:

  1. Create a new .NET 6.0 ASP.NET Web API application by "dotnet new webapi --no-https --name netwebapp".
  2. Open the application in VS Code -> Select "Dapr: Scaffold Dapr Tasks" from Command Palette -> Select ".NET Core Launch (web)" when asked to select a configuration -> Enter an application ID (Select the default "app") -> Enter an application port (Select the default "5000").
  3. Debug with configuration ".NET Core Launch (web) with Dapr".
  4. Click "Restart" button.
    image
  5. Check whether there is no error after clicking "Restart" button.

Expect:
There is no error after clicking "Restart" button.

Actual:
Pop up an error after clicking "Restart" button.
image

More Info:
This is an unstable issue.

On my Mac I also see a daprd process remaining after the daprd-down task runs. There is no error, and I see the terminal says

> Executing task: daprd-down <

Shutting down daprd...

Terminal will be reused by tasks, press any key to close it.

However, that daprd process hangs around, so all of the components (like the file-based local secret store provider) stay alive and I have to forcibly kill the process to get them to reset.

I managed to make it work consistently not using the daprd-down task. Instead I used a shell task and the CLI, as follows.

{
    "version": "2.0.0",
    "tasks": [
        {
            "label": "dapr-debug",
            "type": "dapr",
            "appId": "hnhandler",
            "appProtocol": "grpc",
            "appPort": 5002,
            "grpcPort": 50002,
            "componentsPath": "dapr/components",
            "presentation": {
                "clear": true,
                "focus": true,
           },
        },
        {
            "label": "dapr-down",
            "type": "shell",
            "command":[ "dapr stop --app-id hnhandler" ],
            "presentation": {
                "clear": true,
                "close": true,
                "reveal": "never"
           },
        },
    ]
}

The dapr-down task was from a time before dapr stop existed and even before we could use dapr run, having to start the daprd process directly. Now that dapr stop exists, it might make sense to switch to that and deprecate the dapr-down task.