Grpc.Net.Client weird second request call time out exception
Working on a server-client communication using protobufs. From clients side I use GrpcChannel from the Grpc.Net.Clien package.
Encountering a strange problem, where the second service call to server is throwing an
Interestingly enough, everything on the server's side is working, yet on this second request, the client's side gets an error.
The code bellow that reproduces this bug.
30 Replies
And here is the error of the second service call:
{ "opinion": "USERNAME_OPINION_OK" }
Failed on the 2 request:
Status(StatusCode="Unavailable", Detail="Error starting gRPC call. HttpRequestException: The connection timed out from inactivity. (http://serverUrl) QuicException: The connection timed out from inactivity.", DebugException="System.Net.Http.HttpRequestException: The connection timed out from inactivity. (http://serverUrl)")
{ "opinion": "USERNAME_OPINION_OK" }
{ "opinion": "USERNAME_OPINION_BAD" }
{ "opinion": "USERNAME_OPINION_BAD" }
{ "opinion": "USERNAME_OPINION_BAD" }
Note: on linux mashine the client code works perfectly (tested and approved), while I work on windows 11 and using Visual Studio 2022
Unknown User•9mo ago
Message Not Public
Sign In & Join Server To View
@TeBeCo we are using .NET 8
Unknown User•9mo ago
Message Not Public
Sign In & Join Server To View
The server is idle, and all of the requests happen sequentially
Unknown User•9mo ago
Message Not Public
Sign In & Join Server To View
That's the default for the back-end, which is based on Tonic (Rust)
Unknown User•9mo ago
Message Not Public
Sign In & Join Server To View
Got it
Nvm, the server isn't over QUIC, the highest it does is HTTP/2, not sure why .NET is trying to communicate over it. Not sure how to prohibit it from doing so either, as setting request protocol versions through HttpClient doesn't have an effect.
@TeBeCo if you are interested, using .NET 6, the error does not occur, so the short-term solution, we will just use .NET 6 on this project and not .NET 7-8 (issue also is on the 7th)
Unknown User•9mo ago
Message Not Public
Sign In & Join Server To View
Repro is difficult, we seem to have traced the issue to some bad interaction between the Caddy proxy server and the Windows implementation of HttpClient
Running Kestrel locally is OK, so is running the server locally when a direct connection can be made (localhost:xxxx)
Unknown User•9mo ago
Message Not Public
Sign In & Join Server To View
We were trying to get some minimal reproduction sample going
Unknown User•9mo ago
Message Not Public
Sign In & Join Server To View
Caddy supports HTTP/3 and I think it announces it, although the underlying proxied application might not, as is the case for our back-end, as Tonic only does HTTP/2
Unknown User•9mo ago
Message Not Public
Sign In & Join Server To View
Disabling the
Alt-Svc header on that specific resource fixes the issueUnknown User•9mo ago
Message Not Public
Sign In & Join Server To View
- for a header config in Caddy means to delete the headerheader (Caddyfile directive) - Caddy Documentation
Caddy is a powerful, enterprise-ready, open source web server with automatic HTTPS written in Go
Unknown User•9mo ago
Message Not Public
Sign In & Join Server To View
It does not, the configuration is valid. Simply setting server protocols to
h1 h2 isn't enough to stop this from happening, we had that set before the issue was resolved. header -Alt-Svc seems to be necessary.Unknown User•9mo ago
Message Not Public
Sign In & Join Server To View
Well it works for us now with the header stripped, but we don't know what's causing it, just that it's not our problem
We'll try filing a bug report on the dotnet repo sometime later today
Unknown User•9mo ago
Message Not Public
Sign In & Join Server To View
Will do
Unknown User•9mo ago
Message Not Public
Sign In & Join Server To View