fix(langchain): pass conversation_id as LangGraph thread_id#2074
fix(langchain): pass conversation_id as LangGraph thread_id#2074Rahulreddy1020 wants to merge 2 commits into
Conversation
The langgraph_wrapper invoked the wrapped graph without a RunnableConfig, so any graph compiled with a checkpointer raised "Checkpointer requires one or more of the following 'configurable' keys: thread_id, ..." and checkpoint-backed thread memory never worked when served through NAT. Map NAT's conversation_id (following the existing zep_cloud plugin convention) to LangGraph's thread_id and pass it to ainvoke/astream. When no conversation_id is present, config is None, preserving the prior behavior for stateless graphs. Closes NVIDIA#1994 Signed-off-by: Rahul Reddy <Rahulreddy1020@users.noreply.github.com>
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Enterprise Run ID: 📒 Files selected for processing (2)
🚧 Files skipped from review as they are similar to previous changes (2)
Walkthrough
ChangesConversation-scoped RunnableConfig for LangGraph
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In
`@packages/nvidia_nat_langchain/src/nat/plugins/langchain/langgraph_workflow.py`:
- Around line 111-115: The docstrings at two locations contain the reject-list
term "NAT" which violates coding guidelines for documentation vocabulary. In
packages/nvidia_nat_langchain/src/nat/plugins/langchain/langgraph_workflow.py
lines 111-115, reword the _build_runnable_config method's docstring to remove
"NAT's" while maintaining the focus on the conversation_id to thread_id mapping
concept. In packages/nvidia_nat_langchain/tests/test_langgraph_workflow.py line
209, update the test class docstring to remove the reference to "NAT" while
preserving the description of the mapping behavior being tested. Ensure both
locations remain clear and accurate in describing the functionality without
using the reject-list term.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Enterprise
Run ID: 382b0da7-59ac-4f58-8bd6-b971f05f2394
📒 Files selected for processing (2)
packages/nvidia_nat_langchain/src/nat/plugins/langchain/langgraph_workflow.pypackages/nvidia_nat_langchain/tests/test_langgraph_workflow.py
Address CodeRabbit review: remove the reject-list term from the _build_runnable_config and TestBuildRunnableConfig docstrings while preserving the conversation_id -> thread_id mapping description. Signed-off-by: Rahul Reddy <Rahulreddy1020@users.noreply.github.com>
Description
The
langgraph_wrapperinvoked the wrapped graph without aRunnableConfig, so any graph compiled with a checkpointer raised:As a result, checkpoint-backed thread memory never worked when a LangGraph agent was served through NAT (per #1994).
This maps NAT's
conversation_idto LangGraph'sthread_idand passes it to allainvoke/astreamcalls, following the existingzep_cloudplugin convention (zep_editor.pyusesContext.get().conversation_idas the thread id). When noconversation_idis in context, the config isNone, preserving the current behavior for stateless graphs.Verified empirically against
langgraph1.x:thread_id: memory persists across turns and threads are isolated.thread_idis a harmless no-op, so the change is safe for all graphs.Open questions for maintainers
thread_idbe namespaced byuser_id(e.g.f"{user_id}:{conversation_id}") for stronger multi-user isolation? I followed theconversation_id-only convention already used byzep_cloud, but happy to change.conversation_idis present, the current behavior (no thread id, no persistence) is preserved. Let me know if a synthesized fallback is preferred.Closes #1994
By Submitting this PR I confirm:
TestBuildRunnableConfig; full file: 19 passed.)Summary by CodeRabbit