[Proposal] Pass timeout for Dapr Http Request from DaprClient .Net sdk

[Ashish Pote]

Ability to pass or configure timeout option for service invocation to DaprClient.

Suggestion:

Option 1:

var daprClient = new DaprClientBuilder().Build();
daprClient.httpTimeout = 60; // timeout in second

Option 2:

DaprOptions daprOptions = new() { timeout = 60; method = HttpMethod.Post.ToString() } // Future proof can be used to set more such options in the future

daprClient.InvokeMethodAsync(appId, methodName, daprOptions , cancellationToken);

[Phillip Hoff]

@Ashishpote A couple of initial thoughts:

• The HttpClient used by DaprClient, both for HTTP and gRPC, can be customized and has a Timeout property.
• The HttpClient docs also suggests per-invocation timeouts be implemented using CancellationTokenSource, which can be done with DaprClient methods as well.
• Dapr offers "resiliency" as a building block of its own, which comprehends timeouts and could be used for similar purposes, and/or as part of a larger resiliency policy.

If you don't believe any of these options would work, I'd love to know more about your specific scenarios.

[Phillip Hoff]

Looking more closely, it looks like some of the HttpClient customization mechanisms are meant for testing and not necessarily exposed in the public API, so there may still be more we could do here (see similar issue #756). From the same question on Discord, it seems the scenario isn't applying a specific timeout, but extending the existing (default) HttpClient timeout (which is documented as 100s). (The Dapr runtime method invocation does not have a timeout, unless explicitly configured via resiliency policy.)

There was a suggestion on Discord to use DaprClient.CreateInvokeHttpClient() which returns a HttpClient instance that can then have its Timeout property set. That's admittedly an entirely different way to do method invocation, but should work in the (hopefully) limited case of a specific method requiring more time.

[Ashish Pote]

Agreed. We have indeed been using Resiliency now to have central control over Timeout for both service invocation and pub/sub. However, I would still prefer if we can pass more options by exposing HttpClient directly or indirectly so that we can have control per service.