Hi Kim,
You stated: “the logs did not show any evidence of a faulty Kiota implementation… or any other client-side failure.”
With respect, this is like a doctor looking at an X-ray of a broken arm and saying “I see no evidence of a fracture.”
Here is the exact text from my log file:
15:26:56.142 Request: GET https://people.googleapis.com/v1/people/me/connections...
15:28:36.157 Exception: TaskCanceledException: The request was canceled due to the configured HttpClient.Timeout of 100 seconds elapsing.
at Microsoft.Kiota.Http.HttpClientLibrary.HttpClientRequestAdapter.GetHttpResponseMessageAsync(...)
Fact check:
- “HttpClient.Timeout” is a client-side setting. This is the application’s own code cancelling the request after its internal 100-second timer expires. It is not a server error. It is not an ISP error. It is eM Client giving up.
- “Microsoft.Kiota” appears in the stack trace. This is the library I identified. It’s right there. In the text.
- The 100-second precision rules out network interference. ISP filtering and “upstream devices” do not wait exactly 100.000 seconds before blocking a packet. They act immediately. A perfect 100-second delay is the signature of a hard-coded software timeout — your software timeout.
- The idle-then-fail pattern (visible in the timestamps) is textbook TCP connection pool staleness — the client reuses a connection that NAT infrastructure has already closed. This is a known class of HTTP/2 bugs.
I have provided logs. I have provided timestamps. I have provided stack traces. The evidence is in your own diagnostic output. Repeating “we see no evidence” does not make the text disappear.
For other users experiencing this issue: the workaround posted above (DOTNET_SYSTEM_NET_HTTP_DISABLEHTTP2=1) forces .NET applications to use HTTP/1.1, which handles connection drops more gracefully. I refuse to apply it myself because degrading my entire operating system’s HTTP performance to compensate for one application’s bug is not an acceptable solution.
Regards,
Dmitry