You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on May 27, 2026. It is now read-only.
The AsyncOpenAI, Ollama, and VoyageAI embedders create HTTP clients that are never explicitly closed. Over time, connections accumulate in CLOSE_WAIT state and eventually exhaust available file descriptors.
Symptoms
Too many open files errors after prolonged operation
Connections stuck in CLOSE_WAIT state (visible via ss -tan or netstat)
Gradual file descriptor exhaustion under sustained embedding workloads
Root Cause
The embedder classes instantiate HTTP clients (e.g., httpx.AsyncClient via the OpenAI SDK, or direct httpx usage in Ollama/VoyageAI) but lack cleanup logic to close them when the embedding loop exits.
Summary
The AsyncOpenAI, Ollama, and VoyageAI embedders create HTTP clients that are never explicitly closed. Over time, connections accumulate in
CLOSE_WAITstate and eventually exhaust available file descriptors.Symptoms
Too many open fileserrors after prolonged operationCLOSE_WAITstate (visible viass -tanornetstat)Root Cause
The embedder classes instantiate HTTP clients (e.g.,
httpx.AsyncClientvia the OpenAI SDK, or directhttpxusage in Ollama/VoyageAI) but lack cleanup logic to close them when the embedding loop exits.Proposed Fix
See PR #917, which:
cleanup()method to theEmbedderbase classcleanup()in affected embedders to close underlying HTTP clientscleanup()inExecutor.run()'sfinallyblock