Port exhaustion regression

[ntwilson]

Using FsHttp with the default httpClientFactory on an Azure Web App to send many HTTP requests to the same domain results in SNAT port exhaustion, with the error

System.Net.Sockets.SocketException (10060): A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond.

From what I can tell, this is because the default factory will create a new HttpClient instance for each request. Microsoft documentation states that if you are not using HttpClientFactory with DI, you should have a singleton HttpClient for the lifetime of your application to avoid the port exhaustion problem.

It looks like this problem was fixed in #37, but then reintroduced later.

[SchlenkR]

Thank you very much for submitting this issue. The problem here is that FsHttp allows per-request configuration of the underlying SocketsHttpHandler, which then results in a per-request instance of HttpClient. We could think about something like:

• mark the per-instance httpClientHandlerTransformersand httpClientTransformers as obsolete, and change the behavior of the request generation in a way that if they are not used for a request, a per-process instance of the related SocketsHttpHandler, HttpClient, etc. are used.
• allow a per-process default configuration of these 2 transformers.

[SchlenkR]

/repo-assist Could you comment on this in general? Backward-compatibility is important here...

[github-actions]

🤖 This is an automated response from Repo Assist.

---

Thanks for raising this — it's a real problem with a subtle root cause. Here's an analysis and a backward-compatible path forward.

Root cause

defaultHttpClientFactory in Defaults.fs creates a new SocketsHttpHandler on every invocation (line ~15). Even though the handler is configured with PooledConnectionLifetime = 5 minutes, the connection pool it manages is discarded after each request because both the handler and the HttpClient are disposed in the dispose callback in Request.fs (line 171). So in practice, zero connection reuse is happening — each request opens a fresh TCP connection.

The PooledConnectionLifetime setting is only beneficial if the same SocketsHttpHandler instance services multiple requests. When it's thrown away after one use, it has no effect.

Why the #37 fix regressed

The original fix presumably introduced a singleton handler/client. When per-request configuration (the httpClientHandlerTransformers and httpClientTransformers APIs) was added later, the factory had to start creating new instances per request to accommodate custom handler configuration — silently re-introducing the port exhaustion problem.

Options, keeping backward compatibility in mind

Option 1: Conditional singleton (recommended starting point)

Use a process-scoped Lazy(SocketsHttpHandler * HttpClient) in the default factory. The rule:

• If both httpClientHandlerTransformers and httpClientTransformers are empty → return the cached singleton client, and skip disposal after the request
• Otherwise → fall back to the current per-request creation behaviour

This requires a small tweak to the dispose callback: it should only dispose the client if it was freshly created for that request (not the shared singleton). One clean way to model this is for the factory to return a HttpClient * bool where the bool indicates "caller owns this client", but that changes the httpClientFactory type. Alternatively, the factory could register the singleton in a module-level ref and check identity at disposal time.

Backward-compatible: all existing code that sets transformers continues to work identically. Code that doesn't use transformers (the vast majority of users) automatically benefits from connection pooling with zero changes.

Option 2: Deprecate per-request transformer APIs, introduce global-only configuration

Mark config_transformHttpClientHandler / config_transformHttpClient as [(Obsolete)] and introduce a complementary GlobalConfig-level API for handler/client configuration. The global configuration would initialise a singleton handler once.

Per-request configuration would remain for a deprecation period but emit a warning. In a future major version, it could be removed, allowing the factory to always use the singleton path.

Trade-off: this is a more principled long-term design, but it's a larger change and introduces a deprecation cycle. It works well only if the most important customisations (SSL cert handling, proxy, timeouts) can all be expressed at the global level, which looks feasible given the current config shape.

Option 3: Document the workaround (no behaviour change)

Document clearly that users who care about connection reuse should inject a singleton via config_setHttpClientFactory:

let sharedClient = 
    new HttpClient(new SocketsHttpHandler(PooledConnectionLifetime = TimeSpan.FromMinutes 5.0))

GlobalConfig.defaults
|> Config.setHttpClientFactory (fun _ -> sharedClient)
|> GlobalConfig.set

Note that if the factory returns a shared client, the dispose callback will dispose it — so callers also need to handle that (e.g. a custom factory that wraps a shared client in a non-disposing proxy). This is a real usability obstacle and is easy to get wrong silently.

Recommendation

Option 1 delivers the most value with the least disruption. The key design decision is how to communicate "do not dispose this client" from the factory to the request execution. One approach that avoids changing the httpClientFactory type signature is to cache the singleton in a module-level Lazy<_> and compare the returned instance at disposal time. If obj.ReferenceEquals(finalClient, cachedSingleton.Value) then skip disposal.

Option 2 is worth planning for a future major release as the cleaner long-term model. Option 3 is a reasonable stopgap for documentation in the meantime.

Happy to prototype Option 1 if that would be useful.

Generated by Repo Assist for issue #198 · ◷

To install this agentic workflow, run

gh aw add githubnext/agentics/workflows/repo-assist.md@346204513ecfa08b81566450d7d599556807389f

[github-actions]

🤖 This is an automated response from Repo Assist.

Following up on my earlier analysis: I've submitted a draft PR that implements the fix described as "Option 1" — a process-wide lazy singleton SocketsHttpHandler for the default configuration.

The key change is in Defaults.fs: the default factory now returns a shared handler (with disposeHandler=false) when no proxy, custom handler transformers, or non-default cert/decompression settings are in play. Each request still gets its own HttpClient wrapper, so per-request Timeout and httpClientTransformers continue to work unchanged. Custom factory configurations are unaffected.

Please take a look at the PR and let me know if the approach looks good or if you'd prefer a different design.

Generated by Repo Assist · ◷

To install this agentic workflow, run

gh aw add githubnext/agentics/workflows/repo-assist.md@346204513ecfa08b81566450d7d599556807389f