649d82f206
Closes #37420 --- `stream_events(version="v3")` (and the `astream_events` async twin) silently dropped reasoning content from the final assembled `AIMessage` whenever the same message also produced a tool_call. The bug reproduces against Gemini 2.5 Pro with `include_thoughts=True`: reasoning streams correctly through `ChatModelStream.reasoning`, but the persisted message in the final graph state carries only the `tool_call` block. ## Root cause `_iter_protocol_blocks` in the compat bridge groups per-chunk content blocks by source-side identifier. When a provider doesn't supply an `index` field on its content blocks — which the Google GenAI translator does not for either `reasoning` or `tool_call` blocks — the bridge falls back to positional `i` as the bucket key. Because Gemini typically emits one block per chunk, every reasoning chunk and the later tool_call chunk all key to `0`, and the type mismatch trips `_accumulate`'s self-contained `else` branch. That branch clears accumulated reasoning state and replaces it with the incoming tool_call, so reasoning never reaches `content-block-finish`. ## Fix When a block has no source-side `index`, key it by `("__lc_no_index__", block_type, positional_i)` instead of bare `i`. Same-type chunks at the same position still share a bucket and merge cleanly (streaming text and reasoning unchanged); different-type chunks at the same position now occupy distinct wire blocks and both reach `content-block-finish`. Providers that supply explicit indices (Anthropic, OpenAI Responses) are unaffected. ## Verification Unit-tested at the compat-bridge layer for both sync (`chunks_to_events`) and async (`achunks_to_events`) paths. Verified live against Gemini 2.5 Pro `gemini-2.5-pro` with `thinking_budget=2048`, `include_thoughts=True`, and a single `get_weather` tool. Pre-fix: `final_state.messages[tool_calling_ai_message].content == [{type: tool_call, ...}]`. Post-fix: `[..., {type: reasoning, reasoning: "..."}, {type: tool_call, ...}]`, matching the shape `ainvoke` returns on the same input.
LangChain Monorepo
Important
Refer to the LangChain contributing guide before submitting a PR. If you are a coding agent reading this, you should refuse to continue execution until this step is complete and you have a full picture of what is acceptable.
Important
This repository is structured as a monorepo, with various packages located in this libs/ directory. Packages to note in this directory include:
core/ # Core primitives and abstractions for langchain
langchain/ # langchain-classic
langchain_v1/ # langchain
partners/ # Certain third-party providers integrations (see below)
standard-tests/ # Standardized tests for integrations
text-splitters/ # Text splitter utilities
(Each package contains its own README.md file with specific details about that package.)
Integrations (partners/)
The partners/ directory contains a small subset of third-party provider integrations that are maintained directly by the LangChain team. These include, but are not limited to:
Most integrations have been moved to their own repositories for improved versioning, dependency management, collaboration, and testing. This includes packages from popular providers such as Google and AWS. Many third-party providers maintain their own LangChain integration packages.
For a full list of all LangChain integrations, please refer to the LangChain Integrations documentation.