Description
OllamaProvider uses ollama_rs::Ollama::new(host, port) which internally constructs a reqwest::Client with default (infinite) timeout. Neither a connect timeout nor a request timeout is applied.
The Claude and OpenAI backends use crate::http::llm_client(600) which applies a 30s connect timeout and a 600s request timeout (see crates/zeph-llm/src/http.rs). The Ollama backend lacks equivalent protection.
A hung or slow Ollama server will block the agent indefinitely on .send_chat_messages() or .generate_embeddings() calls, bypassing the agent-loop timeout only if the higher-level tokio::time::timeout wrapper fires first.
The issue: Ollama calls at provider level have no timeout backstop. If the ollama-rs library itself hangs (e.g., on a connect before sending the request), no timeout fires because tokio::time::timeout in the agent loop only wraps the Rust future's await — not the underlying TCP connect that ollama-rs manages internally.
Expected Behavior
OllamaProvider should be constructed with a custom reqwest::Client built via crate::http::llm_client(timeout_secs), similar to ClaudeProvider and OpenAiProvider. The ollama-rs Ollama struct supports a builder that accepts a custom client.
Actual Behavior
Ollama::new(host, port) uses the default reqwest client with no timeout.
Affected code
crates/zeph-llm/src/ollama.rs:117
client: Ollama::new(host, port),
Environment
Description
OllamaProviderusesollama_rs::Ollama::new(host, port)which internally constructs areqwest::Clientwith default (infinite) timeout. Neither a connect timeout nor a request timeout is applied.The Claude and OpenAI backends use
crate::http::llm_client(600)which applies a 30s connect timeout and a 600s request timeout (seecrates/zeph-llm/src/http.rs). The Ollama backend lacks equivalent protection.A hung or slow Ollama server will block the agent indefinitely on
.send_chat_messages()or.generate_embeddings()calls, bypassing the agent-loop timeout only if the higher-leveltokio::time::timeoutwrapper fires first.The issue: Ollama calls at provider level have no timeout backstop. If the ollama-rs library itself hangs (e.g., on a connect before sending the request), no timeout fires because
tokio::time::timeoutin the agent loop only wraps the Rust future's await — not the underlying TCP connect that ollama-rs manages internally.Expected Behavior
OllamaProvidershould be constructed with a customreqwest::Clientbuilt viacrate::http::llm_client(timeout_secs), similar toClaudeProviderandOpenAiProvider. The ollama-rsOllamastruct supports a builder that accepts a custom client.Actual Behavior
Ollama::new(host, port)uses the default reqwest client with no timeout.Affected code
Environment