BerriAI/litellm · info · Exception
HTTP {self.status_code}
Error message
HTTP {self.status_code} What it means
This is LiteLLM's mock HTTP response object (mock_client_factory) mimicking httpx/requests raise_for_status: it raises a plain Exception with 'HTTP {status}' whenever the mocked status code is >= 400. It exists only in tests and mocked transports, so hitting it means your mocked endpoint was configured to return an error status and the code under test called raise_for_status (directly or via litellm's HTTP client wrapper).
Source
Thrown at litellm/integrations/mock_client_factory.py:83
return self._text
@property
def content(self) -> bytes:
"""Return response content."""
return self._content
def json(self) -> dict:
"""Return JSON response data."""
return self._json_data
def read(self) -> bytes:
"""Read response content."""
return self._content
def raise_for_status(self):
"""Raise exception for error status codes."""
if self.status_code >= 400:
raise Exception(f"HTTP {self.status_code}")
def _is_url_match(url, matchers: list[str]) -> bool:
"""Check if URL matches any of the provided matchers."""
try:
parsed_url: Final = httpx.URL(url) if isinstance(url, str) else url
url_str: Final = str(parsed_url).lower()
hostname: Final = parsed_url.host or ""
for matcher in matchers:
if matcher.lower() in url_str or matcher.lower() in hostname.lower():
return True
# Also check for localhost with matcher in path
if hostname in ("localhost", "127.0.0.1"):
for matcher in matchers:
if matcher.lower() in url_str:
return TrueView on GitHub (pinned to 6c2dcb801b)
Solutions
- Update the mock to return a success status (2xx) when you intend the happy path
- If testing error paths, catch this Exception (or httpx.HTTPStatusError in real mode) around the call under test
- Tighten mock URL matchers so error fixtures only match the intended endpoint
- Return realistic error bodies too, since code under test may read response.text/status_code after catching
Example fix
# before
mock_response = MockResponse(status_code=500, json_data={"error": "boom"})
result = client.fetch(url) # raises Exception: HTTP 500 via raise_for_status
# after (happy path)
mock_response = MockResponse(status_code=200, json_data={"id": "ok"})
# or (error path under test)
try:
client.fetch(url)
except Exception as e:
assert "HTTP 500" in str(e) Defensive patterns
Strategy: try-catch
Validate before calling
def mock_will_raise(status_code: int) -> bool:
return status_code >= 400 Try / catch
try:
resp.raise_for_status()
except Exception as e: # mock raises plain Exception, not httpx.HTTPStatusError
assert str(e).startswith("HTTP ")
# handle simulated failure path here Prevention
- Keep error-status mocks on tightly matched URLs
- In tests, assert on status_code/raise_for_status rather than swallowing all exceptions
When it happens
Trigger: Registering a mock handler that returns status 400/401/429/500 and letting litellm's client raise_for_status run; testing retry/backoff paths by simulating API errors; a mock matcher accidentally matching the real request URL with an error fixture.
Common situations: Writing unit tests for litellm HTTP error handling; fixture reuse where an error-response mock matches more URLs than intended (broad matcher strings); asserting behavior after mocked failures.
Related errors
- HTTP handlers lazy import: unknown attribute {name!r}
- OpenMeter logging error: {e.response.text}
- Failed to transform Braintrust response: {str(e)}
- Error apply_db_fixes: {str(e)}
- module {__name__!r} has no attribute {name!r}
AI-assisted analysis of BerriAI/litellm@6c2dcb801b (2026-08-15).
Data as JSON: /api/errors/b40ed02d6c11b570.
Report an issue: GitHub.