fix: llama-down failures answer fast and say what to do - #141
Merged
Conversation
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
With llama-server down, the most common first-run failure was 17 seconds of dead air
followed by the two words
fetch failed— no URL, no diagnosis, no fix. After this changethe same run fails in ~2 seconds and says:
Where the 17 seconds went
createAgentRuntimerunscheckLlamaServer()with the default retry ladder — 5 attempts,exponential backoff, 500·(1+2+4+8+16) = 15.5 s — purely to log a warning
(
bootstrap.ts, the probe never throws). The sidecar'sstart_sessionstatus probe hadthe same ladder. Both now probe once: these are observability probes, and with a
refused connection the retries change nothing — the first real completion is the retry.
The TUI startup gate already probed with
retries: 0; now every probe agrees.The message
New
formatLlamaUnreachableHint(url)inllama-server-health.ts— the shared, actionablewording.
runappends it to the first transport failure (step_error/loop_failed)only when the active text route is the local server — on a cloud route the same
category points at the provider, not llama — and only once per process, so retries
don't bury the log in repeated advice.
Testing
once, not per retry; untouched on cloud routes; untouched for non-transport categories;
loop_faileddecorated the same way. Plus the existing health-check suite (15/15 total).before 17.3 s + bare
fetch failed→ after 2 s, exit 1, hint printed with URL andboth fix commands.
npm run lintclean.Not covered here: the TUI feed still prints the bare
! [transport] fetch failedline —that surface already has the health pill and the startup wizard, and enriching it touches
the reducer path, so it is left for a separate change.