MistralAI Integration Does Not Classify Timeout And Connection Errors As ModelError Subtypes

The _raise_on_error method only runs on HTTP responses, so transport-level exceptions raised by httpx (timeouts, connection errors) bypass LangChain's error classification entirely. Unlike other integrations, langchain-mistralai does not explicitly catch and convert these exceptions in _completion_with_retry and its async counterpart.

Run the following Python snippet with langchain-mistralai installed: import httpx from langchain_core.exceptions import ModelError from langchain_mistralai import ChatMistralAI class FailingClient: def post(self, **kwargs): raise httpx.ConnectTimeout("timed out", request=httpx.Request("POST", "https://api.mistral.ai")) model = ChatMistralAI(model="mistral-small", api_key="k", max_retries=0) model.client = FailingClient() try: model.invoke("hi") except ModelError: print("caught as ModelError") except httpx.TimeoutException as e: print(f"escaped as plain httpx: {type(e).__name__}") Expected: 'caught as ModelError'. Actual: 'escaped as plain httpx: ConnectTimeout'.

1. The new exceptions use multiple inheritance, which can lead to MRO conflicts if the base classes have differing __init__ signatures. However, both httpx exceptions and ModelError accept an optional message and cause, so this should be safe. 2. This fix only covers TimeoutException and ConnectError; other httpx errors like WriteError, ReadError, or ProtocolError will still escape as raw httpx exceptions. Future versions of httpx or Python may introduce new transport exceptions that need similar handling. 3. If the code currently relies on catching raw httpx.ConnectTimeout specifically (not httpx.TimeoutException), that catch will still work because the new error subclasses it, but it will no longer be the exact type; isinstance checks are fine, but exact type comparisons (e.g., type(e) is httpx.ConnectTimeout) would fail. 4. When upgrading, users should test their error handling thoroughly, especially if they have custom retry logic that depends on exception types. 5. No rollback is needed if the fix is reverted by restoring the original try/except (or lack thereof) and removing the new classes; however, any code that began catching MistralAITimeoutError would need adjustment.