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

[LMWF]

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.

[lgmorand]

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`

[CSelvaraj2010]

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

[Phiph]

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

[abogdanov37]

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?

[mukundansundar]

We will look into this as part of milestone 3.

[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.

[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.

[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.

[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.

[mukundansundar]

not stale

[ryan-singleton]

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.

[yaron2]

@mukundansundar @pravinpushkar do either of you have bandwidth to fix this for 1.12?

[pravinpushkar]

@yaron2 I will be able to take up only mid next week. @mukundansundar feel free to take up if you are planning already.

[hhstore]

any update?