BerriAI/litellm · error · APIConnectionError

{original_exception}\n{_redact_string(traceback.format_exc()

Error message

{original_exception}\n{_redact_string(traceback.format_exc())}

What it means

Same unmapped-exception catch-all as the previous case, but for exceptions WITHOUT a 'request' attribute. LiteLLM embeds both the original exception and the full (redacted) Python traceback into the APIConnectionError message, and stubs a fake POST request to api.openai.com so the exception contract is satisfied. The traceback in the message is your primary debugging clue.

Source

Thrown at litellm/litellm_core_utils/exception_mapping_utils.py:2485

                message=f"{exception_provider} BadRequestError : This can happen due to missing AZURE_API_VERSION: {original_exception}",
                model=model,
                llm_provider=custom_llm_provider,
                response=getattr(original_exception, "response", None),
            )
        else:  # ensure generic errors always return APIConnectionError=
            """
            For unmapped exceptions - raise the exception with traceback - https://github.com/BerriAI/litellm/issues/4201
            """
            exception_mapping_worked = True
            if hasattr(original_exception, "request"):
                raise APIConnectionError(
                    message=f"{exception_provider} - {error_str}",
                    llm_provider=custom_llm_provider,
                    model=model,
                    request=getattr(original_exception, "request", None),
                )
            else:
                raise APIConnectionError(
                    message=f"{original_exception}\n{_redact_string(traceback.format_exc())}",
                    llm_provider=custom_llm_provider,
                    model=model,
                    request=httpx.Request(method="POST", url="https://api.openai.com/v1/"),  # stub the request
                )
    except Exception as e:
        # LOGGING
        exception_logging(
            logger_fn=None,
            additional_args={
                "exception_mapping_worked": exception_mapping_worked,
                "original_exception": original_exception,
            },
            exception=e,
        )

        # don't let an error with mapping interrupt the user from receiving an error from the llm api calls
        if exception_mapping_worked:

View on GitHub (pinned to 6c2dcb801b)

Solutions

1. Read the traceback embedded in the message — the last frame names the actual failing code.
2. Align versions: upgrade litellm (pip install -U litellm) and its bundled openai dependency.
3. Report to litellm GitHub with the traceback if it points inside litellm/llms/... adapters.
4. As a stopgap, pin back to the last working litellm version.

Example fix

# before
try:
    litellm.completion(...)
except Exception:
    pass  # traceback lost

# after
try:
    litellm.completion(...)
except litellm.APIConnectionError as e:
    logger.error('litellm internal failure: %s', e.message)  # contains redacted traceback
    raise

try {
  await litellm.completion(...);
} catch (e) {
  if (e instanceof litellm.APIConnectionError) { /* e.message contains redacted traceback — log and report */ }
}

When it happens

Trigger: Errors raised before/after any HTTP request object exists — e.g. errors during client construction, config parsing inside the call path, serialization bugs, or arbitrary exceptions thrown by provider adapters.

Common situations: Version mismatches between litellm and provider SDKs, provider adapter bugs on new API shapes, or non-HTTP exceptions (KeyError, TypeError) escaping adapter code.

AI-assisted analysis of BerriAI/litellm@6c2dcb801b (2026-08-15). Data as JSON: /api/errors/557b46981f62b818. Report an issue: GitHub.