Dapr client InvokeMethodAsync() throws a gRPC error with Tye. Issue with https redirection.
See original GitHub issueDescribe the bug
I am using the Dapr recipe (shown here https://github.com/dotnet/tye/blob/master/docs/recipes/dapr.md) to do a simple service-to-service invocation. The Dapr client fails on InvokeMethodAsync
with a gRPC error.
To Reproduce
var result = await _daprClient.InvokeMethodAsync<MyResult>("myservice", "hello");
Stack Trace:
[orders_f5aa7016-d]: Grpc.Core.RpcException: Status(StatusCode="Unknown", Detail="Temporary Redirect")
[orders_f5aa7016-d]: at Dapr.Client.DaprClientGrpc.MakeGrpcCallHandleError[TResponse](Func`2 callFunc, Metadata headers, CancellationToken cancellationToken)
[orders_f5aa7016-d]: at Dapr.Client.DaprClientGrpc.MakeInvokeRequestAsync(String appId, String methodName, Any data, HTTPExtension httpExtension, CancellationToken cancellationToken)
[orders_f5aa7016-d]: at Dapr.Client.DaprClientGrpc.InvokeMethodAsync[TResponse](String appId, String methodName, HTTPExtension httpExtension, CancellationToken cancellationToken)
I can directly hit the service via (http) postman and get a result back. I can find the dapr side car port via Tye dashboard.
http://localhost:<dapr-port>/v1.0/invoke/myservice/method/hellow
This is the other service being invoked
namespace MyService.Controllers
{
[ApiController]
[Route("[controller]")]
public class HelloController : ControllerBase
{
private readonly ILogger<HelloController> _logger;
public MyServiceController(ILogger<HelloController> logger)
{
_logger = logger;
}
public ActionResult<MyResult> Get()
{
var sentence = "this is a test";
_logger.LogInformation($"{GetType().Name} triggered");
return new MyResult();
}
}
}
Further technical details
- Include the output of
tye --version
: 0.5.0-alpha.20555.1+fae47325b0c8d7dafcdec5d1248191b24b2adc23 - If possible rerun the command with
-v debug
and include the output - The platform (Linux/macOS/Windows): Windows 10 Pro 2004
Issue Analytics
- State:
- Created 3 years ago
- Comments:5 (5 by maintainers)
Top Results From Across the Web
How-To: Invoke services using gRPC
This Go app implements the Greeter proto service and exposes a SayHello method. Run the gRPC server using the Dapr CLI. dapr run...
Read more >azure container apps - enable dapr gRPC leads to 503 errors
GRPC protocol requires explicit server and client grpc based container apps.
Read more >Dapr for .NET Developers - GitHub
Core API project includes middleware to redirect client requests to the HTTPS endpoint. This breaks communication between the Dapr sidecar ...
Read more >Introduction - Learning Dapr [Book]
This allows Dapr to support any programming language that supports HTTP or gRPC without requiring any SDKs for libraries to be included in...
Read more >The Dapr service invocation building block
Any application can invoke a Dapr sidecar by using the native invoke API built into Dapr. The API can be called with either...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Crosslinking to this issue on Dapr: https://github.com/dapr/dapr/issues/1242
Currently Dapr is designed to use unencrypted HTTP to communicate with the app, and it doesn’t follow redirects (hence the error your saw).
I think the reason you’re seeing a “Not found” after disabling the HTTP binding is because the Dapr extension knows that only HTTP will work and explicitly tries to wire that up: https://github.com/dotnet/tye/blob/master/src/Microsoft.Tye.Extensions/Dapr/DaprExtension.cs#L28
In the short team we should at a minimum suggest how to work around this issue (disable HTTPS binding).
It might be good to remove the https endpoint for dapr and log something saying you did.
What comes to mind for me is that suppressing https when Tye infers bindings seems good. When the user specified the bindings explicitly - it seems less-good. I don’t think this code knows whether https was specified by the user or inferred.
Note that we don’t currently support https in production. It’s not really common in k8s scenarios to give every app its own cert.