Summary
During a long graphify extract semantic pass against a local Ollama backend, the run froze indefinitely (observed 20+ minutes, would not self-recover) after the Ollama server stopped responding. --api-timeout 180 was set but did not abort the stuck request. This appears to be a missing/ineffective client-side read timeout on the Ollama path, so a wedged server hangs the whole extract with no error and no adaptive-retry.
Observed behavior
- Semantic extraction progressed normally (e.g.
chunk 40/86 done), then froze — log stopped, no new chunks.
graphify process at 0% CPU (blocked on a socket read, not working).- Ollama had the model loaded but was idle (~0.2% CPU).
- A fresh, independent
curl http://localhost:11434/api/generate -d '{"model":"...","prompt":"ok","stream":false}' also hung >15s — confirming the Ollama server itself had wedged, not graphify.
- The stuck extract never errored or retried; it sat on the dead read until killed. Bouncing
ollama + re-running was the only recovery.
Notably this occurred with --api-timeout 180 set, so whatever timeout is applied to the OpenAI-compatible client (_resolve_api_timeout() in llm.py) did not fire on this Ollama request. Possible causes I can't fully confirm from the outside: the timeout not covering a streaming read, or a per-chunk "hollow response" (I saw output_tokens≈35 truncation warnings just before the freeze) resetting the read clock so a slow trickle never trips the total timeout.
Impact
A single wedged local-LLM request silently stalls an entire multi-hour extract with no error, no progress, and no recovery — easy to mistake for "still working" since the process is alive.
Suggestions
- Ensure
--api-timeout applies as a hard wall-clock read timeout to Ollama requests (including streaming reads), so a hung server aborts the request and lets adaptive-retry fire instead of blocking forever.
- Consider a heartbeat/stall detector: if no chunk completes within N× the per-chunk expected time, fail the chunk (retryable) rather than block.
- Surface a clear "backend appears unresponsive (no bytes in Ns)" error instead of a silent hang.
Environment
- graphifyy 0.9.5,
--backend ollama, --max-concurrency 1, models qwen3-coder-next (extract) / qwen3.5:122b (label), macOS, local Ollama.
I can't hand you a deterministic repro (it depends on the Ollama server wedging under sustained load), but the 0%-CPU-graphify + idle-Ollama + independently-hung-curl signature was reproducible across three separate stalls in one session.
Summary
During a long
graphify extractsemantic pass against a local Ollama backend, the run froze indefinitely (observed 20+ minutes, would not self-recover) after the Ollama server stopped responding.--api-timeout 180was set but did not abort the stuck request. This appears to be a missing/ineffective client-side read timeout on the Ollama path, so a wedged server hangs the whole extract with no error and no adaptive-retry.Observed behavior
chunk 40/86 done), then froze — log stopped, no new chunks.graphifyprocess at 0% CPU (blocked on a socket read, not working).curl http://localhost:11434/api/generate -d '{"model":"...","prompt":"ok","stream":false}'also hung >15s — confirming the Ollama server itself had wedged, not graphify.ollama+ re-running was the only recovery.Notably this occurred with
--api-timeout 180set, so whatever timeout is applied to the OpenAI-compatible client (_resolve_api_timeout()inllm.py) did not fire on this Ollama request. Possible causes I can't fully confirm from the outside: the timeout not covering a streaming read, or a per-chunk "hollow response" (I sawoutput_tokens≈35truncation warnings just before the freeze) resetting the read clock so a slow trickle never trips the total timeout.Impact
A single wedged local-LLM request silently stalls an entire multi-hour extract with no error, no progress, and no recovery — easy to mistake for "still working" since the process is alive.
Suggestions
--api-timeoutapplies as a hard wall-clock read timeout to Ollama requests (including streaming reads), so a hung server aborts the request and lets adaptive-retry fire instead of blocking forever.Environment
--backend ollama,--max-concurrency 1, modelsqwen3-coder-next(extract) /qwen3.5:122b(label), macOS, local Ollama.I can't hand you a deterministic repro (it depends on the Ollama server wedging under sustained load), but the 0%-CPU-graphify + idle-Ollama + independently-hung-curl signature was reproducible across three separate stalls in one session.