langchain-ai/langgraphjs
1
0
Fork 0
mirror of https://github.com/langchain-ai/langgraphjs.git synced 2026-07-23 09:35:22 -04:00
Code Issues 108 Packages Projects Releases 20 Wiki Activity

Feature Request: Pass RunnableConfig to Stores on Operations #181

New Issue
Closed
opened 2026-02-15 17:16:54 -05:00 by yindo · 5 comments
yindo commented 2026-02-15 17:16:54 -05:00
Owner
Copy Link
Copy Source

Originally created by @parmigiano-tech on GitHub (Mar 1, 2025).

Hello LangGraph Team!

We have been adopting langgraph in our AI Agent Suite, and though complex, the flexibility in workflow development is amazing!

We have already created some custom tools we plan on open sourcing soon, for example a LibSQL (Turso) DB Saver for snapshots, and things are evolving swimmingly!

But we now are facing a simple, yet interesting challenge, regarding stores (As in, memory stores, not checkpointers)

Context

Our custom LibSQLSaver has a variant, called DynamicLibSQLSaver, which allows the user to provide the DB credentials at runtime, using the RunnableConfig, in that way, we can dynamically change the database saving the snapshots based on the source tenant (So each tenant has its own isolated Snapshots DB). That works amazingly well

Issue

On this very good start, we were about to start implementing a Store using LibSQL, which is an amazing match, as libsql already has vector search built in, and we intended to do the same dynamic approach, but alas, none of the metods in BaseStore expect to receive the RunnableConfig as a parameter, and it seems there's no way to access it at runtime

======

Is that really the case, or am i missing something?

Originally created by @parmigiano-tech on GitHub (Mar 1, 2025). Hello LangGraph Team! We have been adopting langgraph in our AI Agent Suite, and though complex, the flexibility in workflow development is amazing! We have already created some custom tools we plan on open sourcing soon, for example a LibSQL (Turso) DB Saver for snapshots, and things are evolving swimmingly! But we now are facing a simple, yet interesting challenge, regarding stores (As in, memory stores, not checkpointers) ### Context Our custom LibSQLSaver has a variant, called DynamicLibSQLSaver, which allows the user to provide the DB credentials at runtime, using the RunnableConfig, in that way, we can dynamically change the database saving the snapshots based on the source tenant (So each tenant has its own isolated Snapshots DB). That works amazingly well ### Issue On this very good start, we were about to start implementing a Store using LibSQL, which is an amazing match, as libsql already has vector search built in, and we intended to do the same dynamic approach, but alas, none of the metods in BaseStore expect to receive the RunnableConfig as a parameter, and it seems there's no way to access it at runtime ====== Is that really the case, or am i missing something?
yindo closed this issue 2026-02-15 17:16:54 -05:00
yindo commented 2026-02-15 17:16:55 -05:00
Author
Owner
Copy Link
Copy Source

@benjamincburns commented on GitHub (Mar 2, 2025):

none of the metods in BaseStore expect to receive the RunnableConfig as a parameter, and it seems there's no way to access it at runtime

That's correct. I wasn't here for the original design of this feature, but I think the expectation was that any runtime configuration necessary for the store would be provided during initialization of the store itself. That would mean that in the case where you have user-specific config (e.g. auth details), you'd need to build the store dynamically before invoking your app.

Would this work for your use case? If not, can you share a bit more detail as to why?

@benjamincburns commented on GitHub (Mar 2, 2025): > none of the metods in BaseStore expect to receive the RunnableConfig as a parameter, and it seems there's no way to access it at runtime That's correct. I wasn't here for the original design of this feature, but I think the expectation was that any runtime configuration necessary for the store would be provided during initialization of the store itself. That would mean that in the case where you have user-specific config (e.g. auth details), you'd need to build the store dynamically before invoking your app. Would this work for your use case? If not, can you share a bit more detail as to why?
yindo commented 2026-02-15 17:16:57 -05:00
Author
Owner
Copy Link
Copy Source

@parmigiano-tech commented on GitHub (Mar 2, 2025):

Hello Benjamin!

Thank you for your response!

Passing the configuration at graph compilation could work, but comes with the drawback of having to compile and keep an instance of the graph for each user, and also makes this specific setup harder to simulate and test using the studio interface (which allows editing of configs, very useful to replicate and test out edge scenarios).

For now we ended up skipping the Store "Memory" feature entirely, using tool calls and vanilla langchain VectorSotores, as we can instantiate them dynamically inside the tool call using the run config.

It would be nice though, to be able to use the first class feature, while keeping a single compiled graph instance for multiple users.

As a bonus, our "Dynamic Saver / Store" approach allows for a single Checkpointer/Store instance to be shared between multiple tenants while keeping full separation of data and states.

@parmigiano-tech commented on GitHub (Mar 2, 2025): Hello Benjamin! Thank you for your response! Passing the configuration at graph compilation could work, but comes with the drawback of having to compile and keep an instance of the graph for each user, and also makes this specific setup harder to simulate and test using the studio interface (which allows editing of configs, very useful to replicate and test out edge scenarios). For now we ended up skipping the Store "Memory" feature entirely, using tool calls and vanilla langchain VectorSotores, as we can instantiate them dynamically inside the tool call using the run config. It would be nice though, to be able to use the first class feature, while keeping a single compiled graph instance for multiple users. As a bonus, our "Dynamic Saver / Store" approach allows for a single Checkpointer/Store instance to be shared between multiple tenants while keeping full separation of data and states.
yindo commented 2026-02-15 17:16:57 -05:00
Author
Owner
Copy Link
Copy Source

@benjamincburns commented on GitHub (Mar 3, 2025):

@parmigiano-tech turns out that when implementing the functional API we added a utility function that lets you easily fetch the current config from anywhere, provided you're executing in the same async context as the call to invoke or stream on your graph, but we didn't export it!

So once #933 is merged & released you should be able to call getConfig from your custom put method and it'll return the current invocation's RunnableConfig for you to use however you like 😄.

Preemptive link to the API reference page for it (will stop 404ing once the PR is merged): https://langchain-ai.github.io/langgraphjs/reference/functions/langgraph.getConfig.html

@benjamincburns commented on GitHub (Mar 3, 2025): @parmigiano-tech turns out that when implementing the functional API we added a utility function that lets you easily fetch the current config from anywhere, provided you're executing in the same async context as the call to `invoke` or `stream` on your graph, but we didn't export it! So once #933 is merged & released you should be able to call `getConfig` from your custom `put` method and it'll return the current invocation's `RunnableConfig` for you to use however you like 😄. Preemptive link to the API reference page for it (will stop 404ing once the PR is merged): https://langchain-ai.github.io/langgraphjs/reference/functions/langgraph.getConfig.html
yindo commented 2026-02-15 17:16:57 -05:00
Author
Owner
Copy Link
Copy Source

@parmigiano-tech commented on GitHub (Mar 3, 2025):

That sounds great!!
To be entirely honest, the only reason we held back on using the functional API in our project is the lack of access to the Runnable Config at some points, with this new feature we might even migrate to the functional API all the way

Thanks for the update, will be waiting for the release.

@parmigiano-tech commented on GitHub (Mar 3, 2025): That sounds great!! To be entirely honest, the only reason we held back on using the functional API in our project is the lack of access to the Runnable Config at some points, with this new feature we might even migrate to the functional API all the way Thanks for the update, will be waiting for the release.
yindo commented 2026-02-15 17:16:57 -05:00
Author
Owner
Copy Link
Copy Source

@benjamincburns commented on GitHub (Mar 3, 2025):

FWIW, your entrypoint always gets the config as its second argument - but yeah, getConfig makes it easier to fetch config from tasks 😄

@benjamincburns commented on GitHub (Mar 3, 2025): FWIW, your `entrypoint` always gets the config as its second argument - but yeah, `getConfig` makes it easier to fetch config from tasks 😄
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
bug
checkpointer
docs-needed
documentation
enhancement
good first issue
good writeup
help wanted
invalid
langgraph-supervisor
open-swe-auto
platform
prebuilt
pull-request
Mirrored from GitHub Pull Request
 question
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
yindo
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: langchain-ai/langgraphjs#181
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?