Problem
InngestClient owns a raw HttpClient, isn't IDisposable, and doesn't use IHttpClientFactory. This pattern has several issues:
- Socket exhaustion - Creating multiple clients risks exhausting sockets
- Configuration - Makes global configuration (timeouts, handlers, logging) harder
- Testing - Harder to mock HTTP calls in tests
- Best practices - Doesn't follow .NET HttpClient best practices
Location: Inngest/InngestClient.cs constructors
Suggested Solution
- Use
IHttpClientFactory for HttpClient management
- Register a named/typed client in DI:
services.AddHttpClient<InngestClient>()
- Implement
IDisposable if the client owns any unmanaged resources
- Allow configuration via
IHttpClientBuilder for policies, handlers, etc.
Benefits
- Proper connection pooling and lifecycle management
- Easier to add Polly policies for retries/circuit breakers
- Better testability with
MockHttpMessageHandler
- Follows .NET best practices
Priority
Medium - important for production reliability.
Problem
InngestClientowns a rawHttpClient, isn'tIDisposable, and doesn't useIHttpClientFactory. This pattern has several issues:Location:
Inngest/InngestClient.csconstructorsSuggested Solution
IHttpClientFactoryfor HttpClient managementservices.AddHttpClient<InngestClient>()IDisposableif the client owns any unmanaged resourcesIHttpClientBuilderfor policies, handlers, etc.Benefits
MockHttpMessageHandlerPriority
Medium - important for production reliability.