You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The .NET SDK provides a way to poll for the sidecar health, as well as a convenience method to wait for the sidecar to be ready.
321
-
322
-
#### Poll for health
323
-
This health endpoint returns true when both the sidecar and your application are up (fully initialized).
324
-
325
-
```csharp
326
-
varclient=newDaprClientBuilder().Build();
327
-
328
-
varisDaprReady=awaitclient.CheckHealthAsync();
329
-
330
-
if (isDaprReady)
331
-
{
332
-
// Execute Dapr dependent code.
333
-
}
334
-
```
349
+
While the .NET SDK provides a way to poll for the sidecar health, it is not generally recommended that developer
350
+
utilize this functionality unless they are explicitly using Dapr to also retrieve secrets or configuration values.
335
351
336
-
#### Poll for health (outbound)
337
-
This health endpoint returns true when Dapr has initialized all its components, but may not have finished setting up a communication channel with your application.
352
+
There are two methods available:
353
+
-`CheckOutboundHealthAsync` which queries an outbound readiness endpoint in the Dapr Health API {{% ref health_api#wait-for-specific-health-check-against-outbound-path %}}
354
+
for a successful HTTP status code and reports readiness based on this value.
355
+
-`WaitForSidecarAsync` continuously polls `CheckOutboundHealthAsync` until it returns a successful status code.
338
356
339
-
This is best used when you want to utilize a Dapr component in your startup path, for instance, loading secrets from a secretstore.
340
-
341
-
```csharp
342
-
varclient=newDaprClientBuilder().Build();
357
+
The "outbound" direction refers to the communication outbound from the Dapr runtime to your application. If your
358
+
application doesn't use actors, secret management, configuration retrieval or workflows, the runtime will not attempt
359
+
to create an outbound connection. This means that if your application takes a dependency on `WaitForSidecarAsync`
360
+
without using any of these Dapr components, it will indefinitely lock up during startup as the endpoint will never be established.
A future release will remove these methods altogether and perform this as an internal SDK operation, so neither
363
+
method should be relied on in general. Reach out in the Discord #dotnet-sdk channel for more clarification as
364
+
to whether your scenario may necessitate using this, but in most situations, these methods should not be required.
345
365
346
-
if (isDaprComponentsReady)
347
-
{
348
-
// Execute Dapr component dependent code.
349
-
}
350
-
```
351
-
352
-
#### Wait for sidecar
353
-
The `DaprClient` also provides a helper method to wait for the sidecar to become healthy (components only). When using this method, it is recommended to include a `CancellationToken` to
354
-
allow for the request to timeout. Below is an example of how this is used in the `DaprSecretStoreConfigurationProvider`.
355
-
356
-
```csharp
357
-
// Wait for the Dapr sidecar to report healthy before attempting use Dapr components.
358
-
using (vartokenSource=newCancellationTokenSource(sidecarWaitTimeout))
0 commit comments