-
Notifications
You must be signed in to change notification settings - Fork 334
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Dapr.Extensions.Configuration.AddDaprSecretStore() fails if the sidecar and app are started separately #993
Comments
When you're more specific about the dapr ports being used, it works:
Apparently, the CLI does not use the default ports. Or set the desired port numbers for the dapr client: using var client = new DaprClientBuilder()
.UseHttpEndpoint("http://127.0.0.1:3500")
.UseGrpcEndpoint("http://127.0.0.1:50001")
.Build(); |
This doesn't work. I looked into the SDK code and it is setting these by default already, so setting them yourself to the same ports it already uses does nothing. It still causes the sidecar to block waiting for the app to run. Has anyone else looked into this to see if there are any other options to get this to work? It makes it impossible to use the secret store component. |
It is a (working) example of how you can set the ports you want (even if it's the default). It must match sidecar http/grpc. |
I double checked the environment variables in the pods and it matches them. It still doesn't fix the issue. I think the problem is more that the AddDaprSecretStore method is not waiting long enough for the dapr sidecar to load. I upped the timeout and it seems to have solved it for the moment. |
Is there any update on this issue? |
Expected Behavior
When starting the application after Dapr sidecar,
AddDaprSecretStore()
should not time out and throw exceptions:Actual Behavior
When running the sidecar and the app separately, exception is thrown:
and then the app:
Steps to Reproduce the Problem
I created a Github repo containing minimal .NET 7 project to repeat the issue. The README.md contains more details.
In short:
dapr run --app-id "app" --app-port "5200" --components-path "components"
dotnet run
It seems to me that this behavior was first described in #779 - the sidecar is waiting when the app will start listening on its port, but the app is waiting for sidecar's
healthz/outbound
endpoint to return 2xx statuscode during startup.Also #983 could be related.
Release Note
RELEASE NOTE:
The text was updated successfully, but these errors were encountered: