-
Notifications
You must be signed in to change notification settings - Fork 485
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Do not use grpc.Dial and deprecated DialOptions #5152
Labels
priority/backlog
Issue is approved and in the backlog
Comments
rturner3
added a commit
to rturner3/spire
that referenced
this issue
Dec 17, 2024
Replace usage of deprecated `grpc.Dial()`/`grpc.DialContext()` methods with `grpc.NewClient()`. Also remove usage of `grpc.WithBlock()`, `grpc.FailOnNonTempDialError()`, and `grpc.WithReturnConnectionError()` options. The combination of these changes results in a couple behavioral changes when setting up gRPC clients: 1. gRPC will no longer dial when creating the client. Instead, it will wait until the client is used for the first time with an RPC invocation. 2. gRPC uses the DNS resolver by default when building the `*grpc.ClientConn` using `grpc.NewClient()`, whereas previously it used to resolve addresses the `passthrough` resolver by default. The result of this change in behavior is that for any invocations of `grpc.Dial()`/`grpc.DialContext()` that did not specify a URI scheme, gRPC now implicitly tries to resolve the address passed to `grpc.NewClient()` using DNS. This breaks some assumptions in the code. The workaround to preserve the previous address resolution behavior is to prepend addresses with no scheme defined with the resolver URI scheme `passthrough:`. Also refactored some test-related code in `cmd/spire-server/cli/common` into a new `test/clitest` package, since it is not intended for use in production code. Fixes spiffe#5152. Signed-off-by: Ryan Turner <[email protected]>
rturner3
added a commit
to rturner3/spire
that referenced
this issue
Dec 17, 2024
Replace usage of deprecated `grpc.Dial()`/`grpc.DialContext()` methods with `grpc.NewClient()`. Also remove usage of `grpc.WithBlock()`, `grpc.FailOnNonTempDialError()`, and `grpc.WithReturnConnectionError()` options. The combination of these changes results in a couple behavioral changes when setting up gRPC clients: 1. gRPC will no longer dial when creating the client. Instead, it will wait until the client is used for the first time with an RPC invocation. 2. gRPC uses the DNS resolver by default when building the `*grpc.ClientConn` using `grpc.NewClient()`, whereas previously it used to resolve addresses the `passthrough` resolver by default. The result of this change in behavior is that for any invocations of `grpc.Dial()`/`grpc.DialContext()` that did not specify a URI scheme, gRPC now implicitly tries to resolve the address passed to `grpc.NewClient()` using DNS. This breaks some assumptions in the code. The workaround to preserve the previous address resolution behavior is to prepend addresses with no scheme defined with the resolver URI scheme `passthrough:`. Also refactored some test-related code in `cmd/spire-server/cli/common` into a new `test/clitest` package, since it is not intended for use in production code. Fixes spiffe#5152. Signed-off-by: Ryan Turner <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
SPIRE uses grpc.Dial and the deprecated DialOptions FailOnNonTempDialError, WithBlock, and WithReturnConnectionError.
grpc.Dial is a deprecated function that also creates the same virtual connection pool as grpc.NewClient. However, unlike grpc.NewClient, it immediately starts connecting and supports a few additional DialOptions that control this initial connection attempt. These are: WithBlock, WithTimeout, WithReturnConnectionError, and FailOnNonTempDialError.
FailOnNonTempDialError, WithBlock, and WithReturnConnectionError are three DialOptions that are only supported by Dial because they only affect the behavior of Dial itself. WithBlock causes Dial to wait until the ClientConn reports its State as connectivity.Connected. The other two deal with returning connection errors before the timeout (WithTimeout or on the context when using DialContext).
More information can be found in the Anti-Patterns of Client creation document.
The text was updated successfully, but these errors were encountered: