Help your agent solve problems faster.

Running langgraph dev inside a uv-managed project

Shows how to fix running langgraph dev inside a uv-managed project. Use it when you hit this exact problem. Skip it when your error message or symptom looks different.

create_tool_calling_agent raises ValueError: This function requires a .bind_tools method be implemented on...

The root cause: with_fallbacks wraps the model in a Runnable that hid bind_tools, so the agent factory could not find the method. A maintainer linked the fix in PR #22139, which forwards bind_tools through fallbacks: upgrade to langchain-core>=0.2.2. For the AzureChatOpenAI variant, the fix was importing the model fro…

Problem outcome: unknown

create_tool_calling_agent raises ValueError: This function requires a .bind_tools method be implemented on...

Wrapping a chat model with .with_fallbacks([fallback_model]) and passing the result to create_tool_calling_agent raised ValueError: This function requires a .bind_tools method be implemented on the LLM. The same error also hit AzureChatOpenAI users importing from langchain_community. The code worked fine without with_…

Problem outcome: unknown

Running langgraph dev inside a uv-managed project

If langgraph dev misbehaves inside a uv-managed project, sync the project first (uv sync), then invoke the CLI through uv's Python instead of the bare langgraph dev shim: uv run python -m langgraph_cli dev. That boots the same dev server (API, Studio UI, docs) with your locked dependencies.

LangGraph InvalidUpdateError: Must write to at least one of [...] (state channel name mismatch)

Check that every key your node returns exactly matches a channel name in your state schema; a typo like returning message when the channel is messages produces this error. Also make sure graph.invoke() is called with the required initial state values rather than an empty dict (TypedDict does not support defaults…

Problem outcome: unknown

LangSmith Python SDK memory grows in long-running apps (RunTree kept in memory)

A maintainer confirmed this is expected behavior rather than a leak: the Python SDK keeps the whole run tree (parents, children, inputs/outputs, metadata) in memory while a trace is live, so RSS grows with concurrency and only releases when the root run finishes. For wide fan-outs or long-running apps, reduce pressure…

Problem outcome: unknown

LangSmith Python SDK memory grows in long-running apps (RunTree kept in memory)

Long-running Python app using LangGraph/LangChain (asyncio.gather with create_task, one graph per task). Memory grows steadily over time, but only when LangSmith tracing is enabled. tracemalloc and objgraph show RunTree objects accumulating in memory long after their traces were flushed to the API. langsmith 0.4.27, l…

Problem outcome: unknown

LangGraph InvalidUpdateError: Must write to at least one of [...] (state channel name mismatch)

Running a LangGraph plan-and-execute style graph raised "langgraph.errors.InvalidUpdateError: Must write to at least one of ['input', 'plan', 'past_steps', 'response']" at runtime, even though the graph compiled without issues. The node's update dict did not match any channel in the state schema. One reporter's node r…

Problem outcome: unknown

OpenAIEmbeddings fails against Azure OpenAI: Too many inputs for model

Pass chunk_size=1 when constructing the embeddings: embeddings = OpenAIEmbeddings(chunk_size=1). This was the confirmed fix in the thread and also works through helpers like vectorstore.from_documents() where you can't pass chunk_size yourself. In langchain.js the equivalent option is batchSize (`new OpenAIEmb…

Problem outcome: unknown

OpenAIEmbeddings fails against Azure OpenAI: Too many inputs for model

Using langchain's OpenAIEmbeddings against Azure OpenAI failed with "InvalidRequestError: Too many inputs for model None. The max number of inputs is 1." Azure's embedding endpoint only accepts one input per request, so the default batched embedding calls got rejected. The reporter also noted that OpenAIEmbeddings nee…

Problem outcome: unknown

ValueError: create_tool_calling_agent requires .bind_tools on the LLM when using with_fallbacks

The root cause: with_fallbacks wraps the model in a Runnable that hid bind_tools, so the agent factory could not find the method. A maintainer linked the fix in PR #22139, which forwards bind_tools through fallbacks: upgrade to langchain-core>=0.2.2. For the AzureChatOpenAI variant, the fix was importing the model fro…

Problem outcome: unknown

ValueError: create_tool_calling_agent requires .bind_tools on the LLM when using with_fallbacks

Wrapping a chat model with .with_fallbacks([fallback_model]) and passing the result to create_tool_calling_agent raised ValueError: This function requires a .bind_tools method be implemented on the LLM. The same error also hit AzureChatOpenAI users importing from langchain_community. The code worked fine without with_…

Problem outcome: unknown

streaming not working when using bind_tools with ChatOllama - llm.stream() returns no tokens

The root cause was on the Ollama server side, not in LangChain. A reporter confirmed that updating to the latest Ollama release (which shipped streaming-tool support) fixed streaming with bind_tools, and another confirmed the same behavior: ChatOpenAI pointed at a non-Ollama backend streamed fine with the same code. A…

Problem outcome: unknown

Error in RootListenersTracer.on_chain_end callback: KeyError('answer') while streaming a RAG chain

This warning is non-fatal: the streamed output is unaffected, only the tracing callback hits the missing key. Multiple reporters confirmed it went away after upgrading (langchain 0.2.14 / langchain-core 0.2.32 or later), so upgrading is the fix. As a temporary workaround, downgrading langchain-core to 0.2.22 silenced …

Problem outcome: unknown

streaming not working when using bind_tools with ChatOllama - llm.stream() returns no tokens

Streaming chat responses from an Ollama model (e.g. llama3.1:70b via ChatOllama, or ChatOpenAI pointed at Ollama's /v1 endpoint) with tools bound via llm.bind_tools([...]).stream(). With tools bound, streaming produced no tokens at all and the on_llm_new_token callback never fired, so apps relying on token-by-token ou…

Problem outcome: unknown

Error in RootListenersTracer.on_chain_end callback: KeyError('answer') while streaming a RAG chain

Building a conversational RAG chatbot with create_retrieval_chain wrapped in RunnableWithMessageHistory (input_messages_key="input", history_messages_key="chat_history", output_messages_key="answer"). Calling astream() on the chain printed repeated warnings: Error in RootListenersTracer.on_chain_end callback: KeyError…

Problem outcome: unknown