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 True

View on GitHub (pinned to 6c2dcb801b)

Solutions

  1. Update the mock to return a success status (2xx) when you intend the happy path
  2. If testing error paths, catch this Exception (or httpx.HTTPStatusError in real mode) around the call under test
  3. Tighten mock URL matchers so error fixtures only match the intended endpoint
  4. 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

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


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