Skip to content

Bound post-scan timeout to 180s + cap runaway generation - #15

Merged
jackparnell merged 1 commit into
TheColonyCC:masterfrom
arch-colony:fix/ollama-timeout-upstream
Jun 30, 2026
Merged

jackparnell merged 1 commit into
TheColonyCC:masterfrom
arch-colony:fix/ollama-timeout-upstream

Conversation

@arch-colony

Copy link
Copy Markdown
Collaborator

What

A post scan occasionally hung ~10 minutes before timing out, while most scans finish in seconds. Root cause was the Ollama call config:

  • OLLAMA_TIMEOUT was 600 (10 min) — a single wedged generation blocked the whole scan for that long before the requests read-timeout fired. Lowered to 180.
  • No num_predict — a runaway decode (the usual reason a scan goes slow) had no token cap and ran until that wall-clock timeout. Added num_predict=1024 (a judgement is a small JSON object under format=json; generous headroom, but bounded tokens ⇒ bounded time).

Also hardened call_ollama

  • Split (connect=5s, read=180s) timeout — a dead daemon fails fast instead of burning the read budget on connect.
  • ConnectionError handled distinctly; timeout log now says the model likely wedged.
  • A slow-but-not-timed-out call (>60s) logs a warning — degradation is visible before it becomes a hard timeout.
  • Every failure path still returns None (post retries next run) rather than raising and killing the scan loop.

Tests

New tests/test_ollama.py (12 tests). Full suite: 118 passing.

🤖 Generated with Claude Code

A post scan occasionally hung for ~10 minutes before timing out. Two
causes, both in the Ollama call config:

- OLLAMA_TIMEOUT was 600 (10 min) — a single wedged generation could
  block the whole scan for that long before the requests read-timeout
  fired. Lowered to 180.
- OLLAMA_OPTIONS had no num_predict, so a runaway decode (the usual
  reason a scan goes slow — the model gets stuck repeating) had no token
  limit and ran until it hit that wall-clock timeout. Added num_predict
  =1024: a moderation judgement is a small JSON object (format=json keeps
  it on-task), so this is generous headroom while bounding tokens =>
  bounding time.

Also hardened call_ollama:
- split (connect, read) timeout: a dead daemon now fails in ~5s instead
  of burning the full read budget on connect.
- ConnectionError is handled distinctly ("daemon up?") from a generic
  error, and the timeout log now says the model likely wedged.
- a slow-but-not-timed-out call (> 60s) logs a warning, so degradation
  is visible before it becomes a hard timeout. "If it takes minutes,
  something is wrong" is now surfaced, not silent.

Every failure path still returns None (post retries next run) rather
than raising and killing the scan loop.

Pinned by tests/test_ollama.py (12 tests): the 180s/connect/num_predict
config, the split-timeout wiring, and that timeout / connection-error /
500 / malformed-JSON all return None without raising. Full suite 106
passing.

Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
@jackparnell
jackparnell merged commit b5b98d4 into TheColonyCC:master Jun 30, 2026
3 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants