You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In my opinion, the dotnet SDK provides a more explicit implementation that is better isolated from accidental change.
For example, if the ordering of a dapr runtime init ever changed (accidentally or deliberately), and the dapr http port was open before all components were initialised, then this would cause a break in behaviour.
Therefore, for this reason, I propose that the Java SDK (and other SDKs) should follow the same behaviour as the dotnet SDK and wait for a successful response from v1.0/healthz/outbound rather than just waiting for the dapr http port to be open.
This is my understanding of the relationship between Dapr and the App during init
The text was updated successfully, but these errors were encountered:
olitomlinson
changed the title
[Proposal] Migrate waitForSidecar to v1.0/healthz/outbound to maintain parity with dotnet SDK
[Proposal] Migrate waitForSidecar to v1.0/healthz/outbound to provide parity with dotnet SDK
Aug 30, 2023
Describe the proposal
In
WaitForSidecarAsync
in the dotnet SDK, it waits for a specific health check againstv1.0/healthz/outbound
https://github.com/dapr/dotnet-sdk/blob/17f849b17505b9a61be1e7bd3e69586718b9fdd3/src/Dapr.Client/DaprClientGrpc.cs#L1758-L1785In
waitForSidecar
in the Java SDK, it just waits for the dapr http port to become availablejava-sdk/sdk/src/main/java/io/dapr/client/DaprClientHttp.java
Lines 138 to 146 in cf8040d
In my opinion, the dotnet SDK provides a more explicit implementation that is better isolated from accidental change.
For example, if the ordering of a dapr runtime init ever changed (accidentally or deliberately), and the dapr http port was open before all components were initialised, then this would cause a break in behaviour.
Therefore, for this reason, I propose that the Java SDK (and other SDKs) should follow the same behaviour as the dotnet SDK and wait for a successful response from
v1.0/healthz/outbound
rather than just waiting for the dapr http port to be open.This is my understanding of the relationship between Dapr and the App during init
The text was updated successfully, but these errors were encountered: