Dapr client fail to start at first chance #674
Description
Describe the bug
When starting up all services of the distributed deployment, the dapr clients fail to load at first chance. When the corresponding service host was fast enough to retrieve secrets, it might start up on a second (manual) attempt.
To Reproduce
Steps to reproduce the behavior:
- Set up the distributed docker compose, or soon the new Aspire project.
- Start the project
Expected behavior
All components should be running without errors or warnings (all displayed green) after a short initialization time.
Additional context
The reason for the fail is simple:
The dapr clients expect the app http api to work when they start.
However, the service hosts first wait for a database connection and therefore try to retrieve connection strings as secrets from the dapr client before they do fully start up. So we have a little circular reference, which doesn't work out well.
One solution could be, that the API of the service host is immediately available after start. The functionality (e.g. the connect server, the login server etc.) is made available later.