LangChain Community Reports Streaming Fallback Bug That Can Silently Drop Structured Output

On September 27, 2026, the LangChain community reported a structured output bug: after a model falls back from a streaming interface to a regular call, generated tool data may go unparsed, leaving downstream components without a result and raising no exception. The reported environment uses `langchain-core` 1.6.5, and the issue remains open. [Community report](https://github.com/langchain-ai/langchain/issues/40858)

The reproduction requires no connection to an external model. It uses a custom model that returns a tool call containing a name and age, followed by a Pydantic tool parser. With the same input, `invoke` returns a person object, while `stream` and asynchronous `astream` both produce an empty array when their results are collected. This makes it possible to investigate the issue separately from model generation quality or network failures. [Reproduction and results](https://github.com/langchain-ai/langchain/issues/40858)

The official documentation explains that when a model does not implement native streaming, the streaming interface can fall back to a regular call; setting `disable_streaming=True` also disables streaming. When set to `"tool_calling"`, the fallback is triggered when the request includes a `tools` parameter, not only after the model actually produces a tool call. This compatibility mechanism lets applications keep using the same interface, but subsequent parsing still needs to preserve the message type. [Official API documentation](https://reference.langchain.com/python/langchain-core/language_models/chat_models/BaseChatModel)

A source comparison shows that the cumulative parser wraps the complete message in a generic `BaseMessageChunk`. The tool parser, however, first checks whether the message is an `AIMessage` before reading the standard tool fields. If the type does not match, it checks a legacy additional field; if that field is absent, it returns an empty result. Based on this code path, the core issue appears to be that the transformed message does not reach the correct data-reading branch; the surface behavior alone is not enough to conclude that the model did not respond. [Message transformation implementation](https://github.com/langchain-ai/langchain/blob/master/libs/core/langchain_core/output_parsers/transform.py), [tool parsing implementation](https://github.com/langchain-ai/langchain/blob/master/libs/core/langchain_core/output_parsers/openai_tools.py)

For systems that use tool calls to carry form data, information extraction, or intermediate agent results, this kind of silent failure may lead downstream components to mistake a parsing failure for “no data.” Engineering teams should use a fixed response to compare the regular, synchronous streaming, and asynchronous streaming paths, and check the result count and required fields. The absence of an exception alone is not a sufficient success condition.

The reporter proposed a fix that converts messages into corresponding chunks based on their original message type. As of this review, the issue does not link to a fix PR, and maintainers have not confirmed the full scope of the impact. The current evidence does not support extending the finding to all model providers or all structured output methods. Using a regular call temporarily may help troubleshoot this case, but production services still need validation. Follow-up should track a formal fix and regression tests, particularly whether structured results are still delivered completely when tool streaming is disabled. [Issue status and proposed fix](https://github.com/langchain-ai/langchain/issues/40858)