cli CLI takes a long time to exit on ctrl+c if app has not started

Expected Behavior

A ctrl+c to the cli should immediately kill daprd and the app and return back to the promt.

Actual Behavior

Nothing happens on screen when the user presses ctrl+c. A few seconds later something will print, then a few after that, it'll exit (see below).

Steps to Reproduce the Problem

This is on Windows (but it repros on Linux too), using a modified sample 1 that listens on the wrong app port to repro the problem.

dapr run --app-id nodeapp --app-port 3000 --port 3500 node app.js ... ... == DAPR == time="2020-05-04T16:07:10.3584211-07:00" level=info msg="application protocol: http. waiting on port 3000. This will block until the app is listening on that port." app_id=nodeapp instance=MININT-CCBRPAO scope=dapr.runtime type=log ver=edge

.. .. <user presses ctrl+c, but nothing happens for seconds>> .. ..

Could not update sidecar metadata for cliPID: PUT http://127.0.0.1:3500/v1.0/metadata/cliPID giving up after 5 attempts Updating metadata for app command: node app.js Could not update sidecar metadata for appCommand: PUT http://127.0.0.1:3500/v1.0/metadata/appCommand giving up after 5 attempts You're up and running! Both Dapr and your app logs will appear here.

The repro above is from master. This isn't a regression from 0.6 which had the same behavior, but I do remember a few releases ago the CLI did exit immediately on ctrl+c.

May 04 '20 23:05 LMWF

same behavior here, running the samples, but that's not consistent. When occuring, it says the app is running, which seems running but Dapr list list an "empty" app

`PS E:\Repos\dapr-eshop\src\eshop.catalog\bin\Debug\netcoreapp3.1> dapr list APP ID HTTP PORT GRPC PORT APP PORT COMMAND AGE CREATED PID

      0          0          0                  39s  2020-05-20 13:35.28  6032`

May 20 '20 11:05 lgmorand

I am experiencing a similar behavior, and dapr list is empty. Any help would be appreciated.

dapr run --app-id 'IotHub' --app-port 5000 dotnet run

Could not update sidecar metadata for cliPID: PUT http://127.0.0.1:57193/v1.0/metadata/cliPID giving up after 5 attempts Updating metadata for app command: dotnet run

APP ID HTTP PORT GRPC PORT APP PORT COMMAND AGE CREATED PID 0 0 0 18s 2020-06-02 19:43.31 45808

Jun 03 '20 01:06 CSelvaraj2010

I'm experiencing this too. How did you fix it?

Dec 02 '20 23:12 Phiph

Hi folks! I have the same question? I ran Dapr on Windows machine. In docker ps i see that dapr_placement run on port 6050. I add --dapr-http-port 6050 but have the same behaviour. Any ideas?

Dec 08 '20 21:12 abogdanov37

We will look into this as part of milestone 3.

Dec 12 '20 00:12 mukundansundar

This issue has been automatically marked as stale because it has not had activity in the last 30 days. It will be closed in the next 7 days unless it is tagged (pinned, good first issue, help wanted or triaged/resolved) or other activity occurs. Thank you for your contributions.

Jan 04 '22 01:01 dapr-bot

This issue has been automatically marked as stale because it has not had activity in the last 30 days. It will be closed in the next 7 days unless it is tagged (pinned, good first issue, help wanted or triaged/resolved) or other activity occurs. Thank you for your contributions.

Feb 03 '22 01:02 dapr-bot

This issue has been automatically marked as stale because it has not had activity in the last 30 days. It will be closed in the next 7 days unless it is tagged (pinned, good first issue, help wanted or triaged/resolved) or other activity occurs. Thank you for your contributions.

Mar 21 '22 13:03 dapr-bot

This issue has been automatically closed because it has not had activity in the last 37 days. If this issue is still valid, please ping a maintainer and ask them to label it as pinned, good first issue, help wanted or triaged/resolved. Thank you for your contributions.

Mar 28 '22 13:03 dapr-bot

not stale

Mar 28 '22 14:03 mukundansundar

Any progress on this issue? Troubleshooting and iterating on designs is incredibly inefficient with how long it takes to stop a run invocation that is showing failures. I sometimes find myself waiting up to two minutes after I know that the run is a bust.

I would prefer not to but in order to meet time constraints, I am probably going to need to resort to aliases and scripts that kill Dapr, but I'm concerned about the long term impacts of that considering how often I am going to need to abuse it.