mirror of
https://github.com/langchain-ai/langgraphjs-gen-ui-examples.git
synced 2026-07-01 12:31:37 -04:00
LangGraph dev server (pnpm agent) silently ignores checkpointer and thread_id, blocking local persistence #10
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @ckemmler on GitHub (May 20, 2025).
LangGraph dev server (pnpm agent) silently ignores checkpointer and thread_id, blocking local persistence
🐛 Summary
The pnpm agent dev server silently ignores the checkpointer (e.g. PostgresSaver) and thread_id passed via the frontend UI (agent-chat-ui), even when the graph is compiled correctly via getGraph() and the thread_id is provided through configurable.thread_id.
This makes true local persistence impossible — even though it’s fully supported in the LangGraph core library.
✅ What works
When calling the graph manually using agent.invoke(...), persistence works as expected:
await agent.invoke(
{
messages: [{ role: "user", content: "hello" }],
},
{
configurable: {
thread_id: "debug-thread-1",
},
}
);
Checkpoints are saved to Postgres via PostgresSaver.
❌ What doesn’t work
When running:
pnpm agent
Even with:
• getGraph() exported
• graph.compile({ checkpointer }) used inside it
• await checkpointer.setup() called
• configurable.thread_id passed from the frontend UI
…no persistence happens. No checkpoints are saved to the database, and the checkpointer is never invoked.
⚠️ Warning message observed
When starting the agent server:
This in-memory server is designed for development and testing.
For production use, please use LangGraph Cloud.
This seems to confirm that the local dev server:
• Is hardwired to use in-memory state
• Does not forward the full config (including thread_id) to the graph’s invoke() method
• Cannot support local production use — even if everything else is set up correctly
💥 Why this is a problem
1. It contradicts the open-source positioning. Developers are encouraged to self-host, yet the only working persistence path is via LangGraph Cloud.
2. The UI examples use the dev server, but the dev server doesn’t support the features needed for persistence (despite appearing to).
3. There is no documented workaround short of rewriting the backend to manually call graph.invoke(...).
🔧 What should be fixed
• The dev server should honor checkpointer if provided in getGraph()
• The server should pass configurable.thread_id from the request into the call to graph.invoke(...)
• The docs should be clear about the limitations of pnpm agent, and ideally offer a minimal example of how to self-host a persistent, threaded agent graph without the cloud platform
🙏 Request
Please confirm:
• Is this limitation intentional?
• If so, is there a roadmap for allowing checkpointer to work in the dev server?
• If not, would you accept a PR that wires thread_id + checkpointer into the request handlers?
@hinthornw commented on GitHub (May 20, 2025):
It's by design that the langgraph platform provides its own checkpointer & store and manages its lifecycle, which is why you'll see these callouts sprinkled throughout the docs, and why we have a pretty big section on persistence in langgraph platform/API in our docs.
The server implements many additional endpoints & functionality on top of and alongside the checkpointer/store implementations.
I'm not sure what's contradictory about building a closed-source server with nice features like a UI, scalable task queue, etc. that works well with an open source framework
@ckemmler commented on GitHub (May 21, 2025):
⚠️ Important Warning for Developers Considering LangGraph (Open Source)
Fair enough — LangGraph Cloud is a commercial offering built on top of open-source foundations. The team is clear (when asked) that their hosted platform includes additional services, and they’re entitled to build a business around that.
But this distinction needs to be said loud and clear, up front:
If you intend to use LangGraph in any serious, production-grade, self-hosted context — involving persistent memory, threading, or checkpoints — the open-source tools are deliberately incomplete.
🚧 Key Points Developers Should Understand:
• The core open-source framework (@langchain/langgraph) gives you the building blocks, but not a usable runtime for persistence, multi-user support, or production deployment.
• The dev server (pnpm agent) and UI examples are hardwired to use in-memory state and ignore your checkpointer — even if correctly configured.
• There is no built-in support for persisting thread_id state unless you build your own server or adopt the LangGraph Cloud Platform.
• The LangGraph Cloud (a closed-source, paid service) adds:
• Persistence and checkpointing
• Scalable task queues
• Managed auth, user routing, and more
❗️ Therefore:
Do not be lured into thinking LangGraph is an “open-source solution” in any meaningful production sense. Without the hosted platform, you’re expected to reverse-engineer essential features if you want to self-host.
This is a classic open-core model — fair and valid — but the line between “open” and “closed” needs to be transparent from the start, so teams can make informed architectural decisions without wasting time chasing functionality that simply isn’t there.