Recommendation for planned deprecation of `DaprClientHttp`

[olitomlinson]

Given a DaprClient created like this...

 try (DaprClient client = (new DaprClientBuilder()).build()) {
      ...
 }

...will result in a DaprClientGrpc by default.

When using waitForSidecar method, this exhibits the same behaviour as calling v1.0/healthz -- as this endpoint won't return success until both the components are initialised and the app channel is established.

---

We discovered this because in our Java app we are trying to read secrets from the secret component as part of the app initialisation, therefore before the app channel becomes available.

The impact was the app dead locked with the sidecar. Eventually waitForSidecar timeout elapsed, and the App crashed as it wasn't able to read the secrets that were depended later on.

---

I did some digging in the Java SDK code, and found that I could force the DaprClientBuilder to return a DaprClientHttp by doing the following.

System.getProperties().setProperty(Properties.API_PROTOCOL.getName(), DaprApiProtocol.HTTP.name());
 try (DaprClient client = (new DaprClientBuilder()).build()) {
      ...
 }

In this case, when using waitForSidecar method, this exhibits the same behaviour as calling v1.0/healthz/outbound -- this endpoint returns successfully when the components are established, but the app channel is not yet established. which is exactly what we needed.

The impact was that we could successfully read secrets during the init phase of our Java App, without causing a Deadlock.

Unfortunately, now this means our code depends on a deprecated capability (DaprClientHttp), which is planned to be removed in the next version of the Java SDK, 1.10

---

My ask is that the following changes are made before DaprClientHttp is removed from the SDK.

• Migrate waitForSidecar in DaprClientGrpc to use v1.0/healthz/outbound
  • This would then allow this issue to be closed without fix [Proposal] Migrate waitForSidecar to v1.0/healthz/outbound to provide parity with dotnet SDK #897
• Introduce a new method called healthCheck, which has the same behaviour as calling v1.0/healthz

This will allow a migration path for us, and also bring parity with the dotnet SDK

[artursouza]

I agree with this. Having parity with .Net seems the right thing hung here.

[sicoyle]

@olitomlinson Thank you for having such detailed issues in the Dapr project 🙌 I'm adding this one to a hackathon we're running tomorrow for the Grace Hopper Conference Open Source Day, so hopefully we can get some eyes on it 🤞 😁

[d195]

/assign

[sicoyle]

@d195 Hope you are enjoying the Grace Hopper Conference Open Source Day event! Please let us know if you need help with anything (and when you open a PR with the changes) so we can move this issue in the board to "In review"! Thank youuuuu :)

[cicoyle]

Hey @d195 - were you still working on this?