-
Notifications
You must be signed in to change notification settings - Fork 757
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
The ConfigureHttpClient method is not supported when creating gRPC clients. #4924
Comments
@martintmk can you please take a look at this? As specified above, this is a regression and breaking change, and we are preparing to lock for 8.2 release, so time is running out for fixing this. If fixing this is not trivial, I'd suggest reverting the change that introduced the regression for 8.2, and then we can check on how to better fix the original issue without causing a regression for 8.3. Thoughts? |
* Revert "Update Microsoft.Extensions.Http.Resilience to 8.2 (#2094)" This reverts commit 2bf302b. There is a breaking change with Grpc clients in this version. See dotnet/extensions#4924 * Set the EndToEnd test HttpClient timeout to infinite This allows the Http.Resilience handlers to handle the timeout correctly.
@joperezr Let's just revert that fix for 8.2.0, service owners can still disable the timeout as a workaround. Unless the restrictions around using I must say the behavior of |
+1. @JamesNK, can you clue us in on why this is restricted? |
* Revert "Update Microsoft.Extensions.Http.Resilience to 8.2 (dotnet#2094)" This reverts commit 2bf302b. There is a breaking change with Grpc clients in this version. See dotnet/extensions#4924 * Set the EndToEnd test HttpClient timeout to infinite This allows the Http.Resilience handlers to handle the timeout correctly.
Because it has no impact. It's to let the developer know that this configuration they added to the gRPC client won't do anything. builder.Services.AddGrpcClient<Greeter.GreeterClient>(o =>
{
o.Address = new Uri("https://localhost:5001/");
})
.ConfigureHttpClient(options => options.Timeout = TimeSpan.FromSeconds(10)); // no impact However, now that HttpClientFactory has the concept of applying defaults across all clients it isn't as useful. Changes would be to either add an option to gRPC client factory to suppress the error or changing the error to logging. |
@JamesNK Are there any updates to the suggestion above (suppress the error or log it)? If not, is there a ticket/item to tract it? Thank you. |
There aren't any updates. I've created an issue to track improving gRPC - grpc/grpc-dotnet#2425 I'm really busy so I'm not sure when I'll get time to look at it. |
The issue in grpc-dotnet grpc/grpc-dotnet#2425 was fixed in v2.64.0. We can now reintroduce #4770, and it will not cause the current issue when used together with grpc-dotnet >=v2.64.0. @joperezr @RussKie How do you think if we need to mention in our documentation (or release notes) that our clients need to be on grpc-dotnet >=v2.64.0 not to face the current issue? Or is it enough to mention it here in the current ticket? I personally think that it should be in release notes, and we don't have to include it in our documentation. Thank you. |
dotnet tools, especially those installed globally, aren't updated often (by the user). So, the users likely won't know to update those. It's ok to have the note here and close the issue, if it's resolved by updating to the latest version of grpc-dotnet. However, this isn't very discoverable, and we may see similar issues raised in the future. To advertise the fix more broadly, I think, we could add a note to https://github.com/dotnet/extensions/blob/main/src/Libraries/Microsoft.Extensions.Http.Resilience/README.md (before the "Install the package" section). This won't guarantee that users will necessarily read the docs, but at least we'll be able to close similar issues pointing the users to the docs. We can't really expect users to trawl through our GitHub history looking for a fix. |
Disables HttpClient Timeout for standard resilience and hending handlers
Adds a note mentioning requirements on the Grpc.Net.ClientFactory version to avoid issues with the M.E.Http.Resilience package
Added a target that notifies users that they use a version of the Grpc.Net.ClientFactory package that might cause the dotnet#4924 issue
Revert changes to the Directory.Build.targets
Adds a target that checks whether M.E.Http.Resilience package is used together with Grpc.Net.ClientFactory 2.64.0 or later. If not the target warns a user.
Adds a Known issues section to the doc describing the issue with Grpc.Net.ClientFactory
* Moves the contents of the .props file into the .targets file * For net462 we now import the contents of the .targets file instead of setting it as a CDATA value in the .csproj file
Replaces the name of the project file with the MSBuildProjectName variable
* Add conditions to pack buildTransitive .targets for net462 only when net462 is included as a target framework * Changed the documentation link to the learn.microsoft.com site
* Applies editorial changes to the Known issues section
* Changes the level of the compatibility log messages from Error to Warning * Updates the logic of copying buildTransitive files
To reproduce the issue on NET Framework 4.6.2 we can use the following steps:
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<OutputType>Exe</OutputType>
<TargetFramework>net462</TargetFramework>
<SuppressCheckGrpcNetClientFactoryVersion>false</SuppressCheckGrpcNetClientFactoryVersion>
</PropertyGroup>
<ItemGroup>
<None Remove="Protos\greet.proto" />
</ItemGroup>
<ItemGroup>
<PackageReference Include="Microsoft.Extensions.Http.Resilience" Version="8.10.0-dev" />
<PackageReference Include="Grpc.Net.ClientFactory" Version="2.62.0" />
<PackageReference Include="Google.Protobuf" Version="3.27.0" />
<PackageReference Include="Grpc.Tools" Version="2.62.0">
<IncludeAssets>runtime; build; native; contentfiles; analyzers; buildtransitive</IncludeAssets>
<PrivateAssets>all</PrivateAssets>
</PackageReference>
</ItemGroup>
<ItemGroup>
<Protobuf Include="Protos\greet.proto" GrpcServices="Client" />
</ItemGroup>
</Project>
using GrpcGreeter;
using Microsoft.Extensions.DependencyInjection;
using System;
using System.Threading;
namespace ConsoleApp
{
internal static class Program
{
private static void Main(string[] args)
{
var serviceCollection = new ServiceCollection();
serviceCollection.ConfigureHttpClientDefaults(http =>
{
http.AddStandardResilienceHandler();
});
serviceCollection.AddGrpcClient<Greeter.GreeterClient>(o =>
{
o.Address = new Uri("https://localhost:5001");
});
var serviceProvider = serviceCollection.BuildServiceProvider();
var grpcClient = serviceProvider.GetRequiredService<Greeter.GreeterClient>();
}
}
}
syntax = "proto3";
option csharp_namespace = "GrpcGreeter";
package greet;
// The greeting service definition.
service Greeter {
// Sends a greeting
rpc SayHello (HelloRequest) returns (HelloReply);
}
// The request message containing the user's name.
message HelloRequest {
string name = 1;
}
// The response message containing the greetings.
message HelloReply {
string message = 1;
}
|
I think this works if you use gRPC 2.64.0 or later. It would be great if you could update your grpc package versions to the latest and see whether this is still a problem. |
Correct, we just wanted to have here steps how to reproduce the issue on net462. |
Ok. Just saying, I think you can close this issue. The problem was in grpc and it's been fixed there and released. |
….Net.ClientFactory library (#42476) * Adds a "Known issues" section describing potential issue described here dotnet/extensions#4924 * Apply suggestions from code review --------- Co-authored-by: David Pine <david.pine@microsoft.com>
* Fixes #4924 and #4770 Disables HttpClient Timeout for standard resilience and hending handlers * Fixes #4924 Adds a note mentioning requirements on the Grpc.Net.ClientFactory version to avoid issues with the M.E.Http.Resilience package * Fixes #4924 Added a target that notifies users that they use a version of the Grpc.Net.ClientFactory package that might cause the #4924 issue * Fixes #4924 Revert changes to the Directory.Build.targets * Fixes #4924 Adds a target that checks whether M.E.Http.Resilience package is used together with Grpc.Net.ClientFactory 2.64.0 or later. If not the target warns a user. * Fixes #4924 Adds a Known issues section to the doc describing the issue with Grpc.Net.ClientFactory * Fixes #4924 * Moves the contents of the .props file into the .targets file * For net462 we now import the contents of the .targets file instead of setting it as a CDATA value in the .csproj file * Fixes #4924 Replaces the name of the project file with the MSBuildProjectName variable * Fixes #4924 * Add conditions to pack buildTransitive .targets for net462 only when net462 is included as a target framework * Changed the documentation link to the learn.microsoft.com site * Fixes #4924 * Applies editorial changes to the Known issues section * Fixes #4924 * Changes the level of the compatibility log messages from Error to Warning * Updates the logic of copying buildTransitive files * Removed extra spaces * Applied suggestions to update the documentation * Removed locale from the URL
Description
3654748 is breaking using gRPC clients with Http.Resilience. This is a breaking change from 8.1.
Reproduction Steps
greet.proto:
Expected behavior
The app should work, like it did when I use
<PackageReference Include="Microsoft.Extensions.Http.Resilience" Version="8.2.0-preview.24105.1" />
Actual behavior
The app fails with:
Regression?
Yes, from 8.1
Known Workarounds
Don't call
AddStandardResilienceHandler()
on HttpClients that use gRPC.Configuration
net8.0
Other information
cc @martintmk @geeknoid @joperezr @JamesNK
The text was updated successfully, but these errors were encountered: