LangChain Community Reports Mistral Streaming Errors Are Ignored, Potentially Treating Truncated Answers as Successful Results

A streaming error-handling issue has been reported in LangChain’s Python Mistral integration. An issue published on October 26 says that if a server returns text first and then sends an error event in the same stream, ChatMistralAI may not raise an exception and may instead treat the received chunks as a normal answer. Another participant commented that they reproduced the issue locally; it remains a community report pending confirmation by maintainers. Issue and reproduction code

The report uses httpx.MockTransport to simulate an HTTP 200 SSE response that sends two text chunks followed by a service error, without providing a finish reason or end marker. This does not require calling a real model. The attached results show that all four paths—synchronous streaming, asynchronous streaming, and synchronous and asynchronous calls with streaming enabled—return truncated text with an empty finish reason and raise no exception. The experiment verifies client behavior with simulated events; it does not establish how often this occurs in production. Reproduction results

According to the reporter’s analysis, the stream handler skips events without a choices field, which causes the error message to be ignored. The official documentation confirms that the integration supports token-by-token streaming, native async, and tool calling. For applications using these capabilities, the engineering risk is that a successful return alone may not indicate whether generation is complete; retry and failure monitoring may also lose their trigger signal. This impact is inferred from the reported behavior and still needs validation in real workflows. Integration feature documentation

The commenter proposed checking for error content and raising an exception before skipping the event, and said local tests passed, but the issue does not yet link to a public fix PR. Teams can add the case of an error arriving after partial text to their integration tests and check whether completion status and exceptions are propagated correctly. They should then track maintainer confirmation, a public fix, and a release before deciding on an upgrade plan. Fix status