Repository navigation
fix(llm): ask a server that dropped the connection once more, and let a thinking model finish - #705
Merged
Merged
Conversation
… a thinking model finish A busy Ollama box serving chat, vision and embeddings resets connections while it swaps models, and each reset failed the whole job (42 "Connection reset by peer" job failures on one install). A dropped connection is now retried once after two seconds; timeouts, refusals and HTTP errors still fail at once. A reasoning model given a small max_tokens (conversation titles) spent it all thinking and returned no content; llm.chat now asks again without the limit. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01QmAhBKz3DtXEjcQLTR3jtx
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.
Requested by Adeel · project thread
Description
Before: on a single Ollama box that serves the chat model, a vision model and embeddings, Ollama resets connections while it swaps models, and each
Connection reset by peerfailed the whole job. A reasoning model (Qwen 3) asked for a short answer withmax_tokens, such as a conversation's title, spent the whole budget thinking. It returnedcontent: "", so the title came back as "the model didn't write a title".After: when the server drops the connection (reset, aborted, or a remote disconnect), Lens waits two seconds and asks once more. Timeouts, refusals and HTTP errors still fail at once, with the same message. When
llm.chatgets an empty answer cut at the length limit, it asks again withoutmax_tokens.Motivation and Context
This comes from Adeel's install, which was moved from Gemini to a LAN Ollama on 10-16. Its activity ledger had zero failures on Gemini. Since the move, the job errors include 42
can't reach the LLM server … [Errno 104] Connection reset by peer, 16 rawConnectionResetErrorand about 70 timeouts at 300 s. Probes from inside the install showed the server, key and models are fine:/modelsreturns 200, gemma3 takes 19.6 s on a reload, and Qwen withmax_tokens: 5returnscontent ""andfinish_reason "length"with the answer inreasoning.Steps to reproduce (if appropriate):
See
tests/domain/test_llm_resilience.py.Types of changes
!in the title)Checklist:
make hookschecks it on commit).docs/accordingly (configuration.md, "A busy local model server").changelog.d/llm-retry-dropped.md.Done questions (AGENTS.md)
llm._post, so the assistant, MCP and API paths all benefit.keep_aliveper request through its native API, so models stay loaded without the user having to setOLLAMA_KEEP_ALIVE.unthinkand the existing_postfallback.Generated by Claude Code