BerriAI/litellm · error · LangGraphError

Error processing response: {e}

Error message

Error processing response: {e}

What it means

While transforming a (non-streaming) LangGraph response into a ModelResponse, any unexpected exception — malformed JSON structure, missing expected fields, type errors during usage calculation fallbacks — is caught, logged, and re-raised as LangGraphError with the original exception text and the raw response's status code. This is a generic wrapper: the real cause is the embedded exception message.

Source

Thrown at litellm/llms/langgraph/chat/transformation.py:460

                prompt_tokens: Final = token_counter(model="gpt-3.5-turbo", messages=messages)
                completion_tokens = token_counter(model="gpt-3.5-turbo", text=content, count_response_tokens=True)
                total_tokens: Final = prompt_tokens + completion_tokens

                usage: Final = Usage(
                    prompt_tokens=prompt_tokens,
                    completion_tokens=completion_tokens,
                    total_tokens=total_tokens,
                )
                setattr(model_response, "usage", usage)
            except Exception as e:
                verbose_logger.warning("Failed to calculate token usage: %s", e)

            return model_response

        except Exception as e:
            verbose_logger.error("Error processing LangGraph response: %s", e)
            raise LangGraphError(
                message=f"Error processing response: {e}",
                status_code=raw_response.status_code,
            )

    def validate_environment(
        self,
        headers: dict,
        model: str,
        messages: list[AllMessageValues],
        optional_params: dict,
        litellm_params: dict,
        api_key: str | None = None,
        api_base: str | None = None,
    ) -> dict:
        """
        Validate and set up environment for LangGraph requests.
        """
        headers["Content-Type"] = "application/json"

View on GitHub (pinned to 6c2dcb801b)

Solutions

  1. Read the wrapped exception text in the message — it names the actual field/parse failure
  2. Reproduce with a direct curl to {api_base}/runs/wait and inspect the JSON envelope
  3. Pin/align the LangGraph server version with what this LiteLLM release supports
  4. Ensure the graph completes successfully in the LangGraph playground before routing through LiteLLM
  5. Upgrade LiteLLM if a newer release adapted to the new response schema
Defensive patterns

Strategy: try-catch

Try / catch

try:
    resp = await litellm.acompletion(model="langgraph/agent", messages=msgs)
except LangGraphError as e:
    if "Error processing response" in str(e):
        # inspect embedded cause; log raw body via verbose logging to classify schema drift vs. run failure
        log.error("LangGraph transform failed: %s (status=%s)", e, getattr(e, "status_code", None))
        raise

Prevention

When it happens

Trigger: LangGraph returns 200 but with a body shape LiteLLM does not expect (e.g. error field inside a 200 response, changed event/result envelope after a server version bump, or HTML body from an intermediary); a graph run that fails mid-execution but still yields a 200.

Common situations: LangGraph Platform/server version drift changing the response schema; a graph raising internally so the result payload lacks expected keys; proxies or middleware mutating the response body.

Related errors


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