search

dapr / dotnet-sdk

Dapr SDK for .NET
Apache License 2.0
1.12k stars 340 forks source link

WaitForSidecarAsync should accept input as to which sidecar [optional?] services to wait for (with timeout) #1351

Open oising opened 2 months ago

oising commented 2 months ago

Describe the feature

Example: With DAPR workflows hosted in an app that also listens to a binding or pubsub (i.e. it declares an appPort), there is a race condition between the DAPR sidecar detecting the appPort as open, and the actor runtime initializing. DAPR blocks until it detects all declared appPorts, and only initializes the actor runtime after this has completed.

Meanwhile, any app that tries to start a workflow after calling daprClient.WaitForSideAsync() -- which returns before the actor runtime is ready -- the call to ScheduleNewWorkflowAsync fails with an "actor runtime is not configured" error.

Retrying the ScheduleNewWorkflowAsync call after a few seconds generally succeeds, but it seems that WaitForSidecarAsync should not return until all declared services are truly ready.

I suggest allowing which services to wait for, along with a timeout (default timeout 30 seconds, perhaps.) I understand that the actor runtime is not a foundational service as it needs a dedicated statestore configured, but this is why we need this method parameterized.

e.g.

public async Task WaitForSidecarAsync(WaitForSidecarOptions options, CancellationToken token);

public record WaitForSidecarOptions(... RequireActorRuntime = false);

Release Note

RELEASE NOTE:

WhitWaldo commented 1 month ago

I think there's a great opportunity to improve on how the .NET client handles readiness and liveness checks of the various sidecar services in general and it's something I'm going to be looking at in the next release, but I don't know I've got the free time this cycle.

I was reading through another open-source project that seeks to help Dapr in this respect that has a far richer "is it live" mechanism than the .NET client currently has, so I think there's definitely a need to get this into a better place.

Increasingly, we're moving to smaller, block-specific clients that would only look for the availability of those services that facilitate whatever they rely on, so I don't know that we'd necessarily need options like your suggestion, but I agree this is something useful to look at iterating on.