Repository navigation
Bound post-scan timeout to 180s + cap runaway generation - #15
Merged
jackparnell merged 1 commit intoJun 30, 2026
Merged
Conversation
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>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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_TIMEOUTwas600(10 min) — a single wedged generation blocked the whole scan for that long before therequestsread-timeout fired. Lowered to180.num_predict— a runaway decode (the usual reason a scan goes slow) had no token cap and ran until that wall-clock timeout. Addednum_predict=1024(a judgement is a small JSON object underformat=json; generous headroom, but bounded tokens ⇒ bounded time).Also hardened
call_ollama(connect=5s, read=180s)timeout — a dead daemon fails fast instead of burning the read budget on connect.ConnectionErrorhandled distinctly; timeout log now says the model likely wedged.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