LiteLLM ollama_chat streaming: structured {'error': ...} from Ollama raises KeyError: 'message' surfaced as APIConnectionError

Finding: In a reported LiteLLM case (v1.85.0, ollama_chat with streaming and tools via the proxy), when Ollama returns a structured error object instead of a normal chunk, LiteLLM raises KeyError: 'message'. The error is wrapped as OllamaError and surfaces to callers as APIConnectionError, so an upstream error can look like a connection or timeout failure. Source: https://github.com/BerriAI/litellm/issues/33622. This is an external report; KFA has not reproduced it. Reported symptom: the reporter says an Ollama error about parsing a malformed tool call (a stray bracket in the model's JSON) was logged by their agent runtime as a timeout. They say this cost two days of misdiagnosis at the network and inference-host level, and that all Ollama_chat exceptions they saw in 48h (11 occurrences) were this one. The reporter also says the upstream error text never reaches the caller in a usable form (issue body). Reporter's hypothesis, not maintainer-confirmed: the streaming handler in litellm/llms/ollama/chat/transformation.py reads chunk['message'] without checking for an 'error' key. The resulting KeyError is caught and re-raised as OllamaError with the KeyError text in the message. The reporter adds that the non-streaming path makes similar assumptions about the 'message' field, and that a default in an eval_count lookup is evaluated eagerly (issue body). The reporter states these line references were verified against main and that upgrading does not fix them; this is unverified here. Diagnostic hint (reported, not verified by KFA): if an ollama_chat stream fails with APIConnectionError containing KeyError: 'message' and 'Got unexpected response from Ollama', the embedded dictionary may hold Ollama's real error text. Read that text before investigating network or host problems. Fix status: proposed only. A commenter (association NONE) volunteered to raise OllamaError when an error key is present on both paths, with tests. A later commenter says PR #45583 matches the reporter's suggestion and raised two concerns. First, mapping every upstream error to status 400 could make server-side faults and rate limits non-retryable for routers, while a malformed tool call may succeed on retry. Second, a test through the exception mapping should pin the surfaced error class (comments linked above). No maintainer response, merge, or release is visible in the supplied data. PR #45583 was not supplied, so its state is unknown. Limitations: single external report; thread coverage may omit middle comments; no workaround was stated; cause is unconfirmed by maintainers; no KFA reproduction.