The HttpClient Bug That Teaches a Lesson Every .NET Team Learns Eventually

Wed, 26 Aug 2026 15:19:19 +0000

Real story from a large scale platform implementation, not a hypothetical.

We started seeing "Faulted" dependency calls in Application Insights — requests hanging for over a minute, then dying. Customers hitting timeouts on live API calls.

Root cause, once we traced it: HttpClient instances pulled from IHttpClientFactory were being wrapped in using blocks and disposed after every single call.

That one habit — copied from a hundred StackOverflow answers — was quietly closing pooled connections the factory was designed to keep alive, forcing new handlers to spin up under load, and exhausting the connection pool exactly when traffic spiked.

The fix wasn't clever. It was disciplined: → Stop disposing factory-managed clients → Replace blocking .GetAwaiter().GetResult() chains with real async → Right-size timeouts (120s → 30s) so failures surface fast instead of hanging → Tune SocketsHttpHandler pooling explicitly instead of trusting defaults

The best infrastructure lessons aren't abstract. They're "we found the bug in production, understood exactly why, and fixed the pattern everywhere it appeared" — not just the one call site that paged someone.

For more details read my other

post

Coder Legion - Recent posts tagged httpclient

The HttpClient Bug That Teaches a Lesson Every .NET Team Learns Eventually