cli
cli copied to clipboard
dapr
`dapr invokeGet/invokePost` cannot be used when `daprd` used directly
Repro Steps
- Start an application
- Start
daprdfor the application with appropriate arguments (e.g.daprd --app-id <app-id> --app-port <app-port> ...) - Run
dapr invoke --app-id <app-id> --method <controller endpoint> --payload <body>
Expected Behavior
The application endpoint is invoked and its response is returned to the console.
Actual Behavior
The invocation will fail with the error:
Error invoking app <app-id>: App ID <app-id> not found.
Discussion
This appears due to the fact that dapr builds the Dapr endpoint for the application using a list of running Dapr applications, but only applications started using dapr run ... are included in that list; applications using Dapr via daprd directly are not included (see #220). There are scenarios where applications must be started alongside daprd rather than via dapr run ... (such as debugging of .NET Core applications), where it would be useful for users/tools to be able to invoke the application via the Dapr CLI rather than another tool and hand-crafting the complete endpoint.
An upvote for this from https://github.com/dotnet/tye - we're building tooling as well, and need to control the launching of the underlying applications as well as their listening ports. We're able to get everything we want accomplished by automating daprd directly, except it doesn't interop with the dapr commands, or the VSCode UI (which I assume is based on dapr list.
...or the VSCode UI (which I assume is based on dapr list.
@rynowak The Dapr extension for VS Code looks for daprd processes (because dapr list doesn't count daprd instances started outside of the dapr CLI, so won't list instances started by the extension for debugging purposes). In addition, there's an inherent limitation that the dapr CLI only knows about instances started on the local machine and not across the network (e.g. in separate VS Code Dev Containers sharing a common Docker network because, say, you want to connect a Node.js application with a .NET Core application yet have entirely separate development environments). I've filed dapr/dapr#1186 that, if implemented, would allow both dapr and other tools to better enumerate running applications.
@philliphoff - is there a good place for us to follow up about the VSCode issue? Detection of daprd processes started by tye run isn't working for me, and I made the assumption that it's related to this issue.
@rynowak Feel free to file an issue in the vscode-dapr repo. The extension is fairly strict in the process command line that it's looking for (to avoid false-positives) so it's entirely possible that it's just ignoring tye's processes because it doesn't recognize an argument.
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.
