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
- Read the wrapped exception text in the message — it names the actual field/parse failure
- Reproduce with a direct curl to {api_base}/runs/wait and inspect the JSON envelope
- Pin/align the LangGraph server version with what this LiteLLM release supports
- Ensure the graph completes successfully in the LangGraph playground before routing through LiteLLM
- 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
- Pin both LiteLLM and LangGraph server versions; re-run integration tests on any upgrade
- Keep a golden-file test of the expected /runs/wait response envelope to catch schema drift early
- Ensure graphs raise cleanly instead of returning 200 bodies with embedded error payloads
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
- Failed to parse Braintrust API response: {str(e)}
- Error apply_db_fixes: {str(e)}
- No audio part found in the response
- ImageVariationConfig implements 'transform_response_image_va
- ImageVariationConfig implements 'transform_response_image_va
AI-assisted analysis of BerriAI/litellm@6c2dcb801b (2026-08-15).
Data as JSON: /api/errors/44e27d9c139088fc.
Report an issue: GitHub.