BerriAI/litellm · error · Exception

error - {e}, Received response - {raw_response}, Type of res

Error message

error - {e}, Received response - {raw_response}, Type of response - {type(raw_response)}

What it means

Generic exception path at the end of the sync make_openai_chat_completion_request (litellm/llms/openai/openai.py:484). If any exception fires after a raw_response was already received — typically raw_response.parse() failing on a malformed body — litellm re-raises a bare Exception (not OpenAIError) whose message embeds the original exception, the repr of the raw response, and its type. Because it is a plain Exception, upstream status codes and headers are lost, and only a broad except Exception catches it.

Source

Thrown at litellm/llms/openai/openai.py:484

                headers = dict(raw_response.headers)
            else:
                headers = {}
            response: Final = raw_response.parse()
            if not data.get("stream") and not hasattr(response, "model_dump"):
                raise OpenAIError(
                    status_code=500,
                    message=f"Empty or invalid response from LLM endpoint. Received: {response!r}. Check the reverse proxy or model server configuration.",
                )
            return headers, response
        except OpenAIError:
            raise
        except openai.BadRequestError as e:
            if not is_output_token_limit_error(e):
                raise
            return build_output_token_limit_response(e=e, data=data, is_async=False)
        except Exception as e:
            if raw_response is not None:
                raise Exception(
                    f"error - {e}, Received response - {raw_response}, Type of response - {type(raw_response)}"
                )
            else:
                raise e

    async def _call_agentic_completion_hooks_openai(
        self,
        response: object,
        model: str,
        messages: list[dict],
        optional_params: dict,
        logging_obj: LiteLLMLoggingObj,
        stream: bool,
        litellm_params: dict,
    ) -> object | None:
        """
        Call agentic completion hooks for all custom loggers (OpenAI Chat Completions API).

View on GitHub (pinned to 77b7c6c40c)

Solutions

Read the message — the repr of raw_response shows the exact bytes the server sent
Reproduce with curl and validate the body against the OpenAI ChatCompletion schema
Align the openai SDK version with what litellm expects (pip install -U openai litellm)
Fix the server or proxy emitting the malformed body
If the repr shows an HTML page, the api_base path is wrong — fix the route, not the parser

Defensive patterns

Strategy: try-catch

Validate before calling

import httpx, json

def upstream_body_is_valid_json(api_base: str, api_key: str, model: str) -> bool:
    r = httpx.post(
        f'{api_base.rstrip("/")}/chat/completions',
        headers={'Authorization': f'Bearer {api_key}'},
        json={'model': model, 'messages': [{'role': 'user', 'content': 'ping'}]},
        timeout=30,
    )
    try:
        body = json.loads(r.text)
    except json.JSONDecodeError:
        return False
    return isinstance(body, dict) and 'choices' in body

Try / catch

from litellm.llms.openai.common_utils import OpenAIError

try:
    resp = litellm.completion(model=m, messages=msgs)
except OpenAIError:
    raise
except Exception as e:  # error 1784 is raised as a bare Exception
    msg = str(e)
    if 'Received response' in msg and 'Type of response' in msg:
        capture_for_debugging(msg)  # message embeds the raw payload repr
    raise

Prevention

Contract-test custom servers against the OpenAI ChatCompletion schema in CI
Pin openai and litellm versions together and upgrade them together
Log full exception messages — the embedded raw response repr is the only diagnostic
Watch for BOM- or whitespace-prefixed JSON from gateways; strip it server-side

When it happens

Trigger: The OpenAI SDK received a 200 response whose body cannot be parsed into a ChatCompletion: invalid JSON, wrong schema, BOM or whitespace-prefixed payloads; proxies injecting content; version skew where parse() yields a non-pydantic object that fails a later attribute access.

Common situations: Homegrown API gateways and legacy serving stacks emitting non-standard fields; SSL-inspecting middleboxes corrupting bodies; pinned old openai SDK versions against newer server payloads.

Related errors

AI-assisted analysis of BerriAI/litellm@77b7c6c40c (2026-08-18). Data as JSON: /api/errors/66e55544c4f4097c. Report an issue: GitHub.