How to correctly use AsyncDuckDBSaver in Langgraph to avoid compiling every time, otherwise conn is closed

[tianshangwuyun]

async with CustomMemorySaver.from_conn_string("data/db_duck.db") as memory:
app = self.workflow.compile(checkpointer=self.memory, store=self.store)
app.astream_events()
This method requires compiling every time the API is called, otherwise conn maybe is closed,

The internal method of memory holds the conn, which may have already been closed when calling the method. There is no connection pool or other way to create a connection every time the method is called, instead of holding the conn

Is there any other better way to avoid compiling every time and also avoid 'con is closed'

Or modify this method to add
with duckdb.connect(conn_string) as conn:

@asynccontextmanager
async def _cursor(self) -> AsyncIterator[duckdb.DuckDBPyConnection]:
async with self.lock:
with self.conn.cursor() as cur:
yield cur

[vbarda]

@tianshangwuyun you can just define the connection on our own and pass it to the DuckDB checkpointer like this

conn = duckdb.connect(conn_string)
checkpointer = AsyncDuckDBSaver(conn=conn)
# use checkpointer here
# ...
conn.close()

https://github.com/langchain-ai/langgraph/blob/main/libs/checkpoint-duckdb/langgraph/checkpoint/duckdb/aio.py#L25

hope this helps!

[tianshangwuyun]

I know this method, but if the objects built in this way are used to compile graphs, for example, in FastAPI, this connection instance may be initialized at the beginning of the lifecycle and closed at the end. This way, there is only one instance object globally, which avoids the problem of duplicate compilation. However, there is only one con globally, which may be disconnected at any time for other reasons and cause new problems

And in this way, due to the constant need to call the close method, the graph still needs to be recompiled when actually requested

I feel that due to the fact that Asynchronous DuckDBSaver holds a conn, it is necessary to use a multi instance object approach and compile the graph every time. There is no other good way to avoid compiling the graph multiple times

compiled_graph.update_state also relies on compiled objects, which leads to the need for compilation when updating the state, causing more problems

This also leads to the construction of the entire graph, which must be rebuilt every time a request involves using CompiledStateGraph. Does this cause performance issues

duckdb not like redis ，redis has pools, it can init when fastapi started and close when fastapi shutdown

Is it the correct approach to compile the graph every time a request is made,Are there any performance or other issues。
for example

async def compile_graph(self, conn):
        store = AsyncDuckDBStore(conn)
        await store.setup()
        memory = AsyncDuckDBSaver(conn)
        await memory.setup()
        compiled_graph = self.graph.compile(checkpointer=memory, store=store)
        return compiled_graph

async def stream(self):
       thread_config = {} ##some config
       try:
          con = duckdb.connect("data/db_duck.db")
          compiled_graph = await self.compile_graph(con)
          async for event in compiled_graph.astream_events():
                   #yeild ...
        finally:
            con.close()
            
async def update_status(self):
          with duckdb.connect("data/db_duck.db") as conn:
            compiled_graph = await self.compile_graph(conn)
            await compiled_graph.aupdate_state(
                thread_config, {"execute_result": [result]}
            )  

[vbarda]

ah, i see your point. calling graph.compile() should not cause any performance issues, so it's fine to re-compile. also, i would suggest using Postgres checkpointer -- with Postgres you can use a connection pool and that should address some of the concerns you mentioned