Surface information about failed InvokeMethodAsync (and others) failures

[atrauzzi]

Expected Behavior

I would have liked to have somehow obtained more easily viewed errors when a call to the sidecar fails. Including telemetry and structured logs so that I can eventually get the feedback in Aspire.

Actual Behavior

No log output, nothing helpful in exceptions. I have to see HTTP JSON output from the sidecar just to know what went wrong.

Steps to Reproduce the Problem

Configure a dapr HTTPEndpoint (not an Aspire HTTP endpoint 😆), make sure it uses https and point it to something that is hosting with an invalid certificate.

Try to call the HTTPEndpoint via dapr.

[WhitWaldo]

More to this issue in particular, the request was returning as a 500 despite being a certificate validation failure, which should instead be in the 400s. Also, the SDK returned nothing about what the issue itself was even though the same request done manually through the service invocation HTTP API yielded the following (redacted) error (which itself also was returned as a 500):

{
"errorCode": "ERR_DIRECT_INVOKE",
"message": "failed to invoke, id: dapr-app-id, err: Get "https://auth.justanotherwebsite.com/api/v3/admin/version\": tls: failed to verify certificate: x509: certificate is not valid for any names, but wanted to match auth.justanotherwebsite.com"
}

The SDK should instead surface whatever errors are provided by the runtime to help in debugging issues without having to resort to methods outside of the SDK.

[KrylixZA]

Just gonna bump this particular issue as we struggle with visibility into errors in production. We feel this problem on actor comms, but it is generally true for a lot of interactions with the Dapr Client. The nature of the exceptions is not very specific and struggles to surface the root cause of the issue and the error messages are generally pretty vague.

I'd love it if the client could surface more details in the exception messages.

[WhitWaldo]

After chatting with @ngruson about opportunities here, we likely need to modify the generic client builder to include a UseLoggerFactory() that takes an ILoggerFactory which makes a logger available to the various clients as needed. That said, I hesitate to do this immediately as the service invocation bits live in Dapr.Client and while useful, this is a fairly niche use case adding that today.

That said, I propose that we revisit this later on in 1.16 when we create the separate package for the invocation functionality. Add the Use statement as part of that work and utilize it in this package to log the message property on response bodies whenever the status code is 500 as in the above example.

[atrauzzi]

Shouldn't the clients be obtaining the factory through injection, not static configuration?