PostgresChatMessageHistory API break the usage of LCEL and Langserv #8

New Issue

2026-02-16T05:16:02-05:00

yindo commented

2026-02-16 05:16:02 -05:00

Originally created by @pprados on GitHub (Apr 25, 2024).

The constructor of PostgresChatMessageHistory accepts only sync or async connection, and not an Engine.

First, the connection was open in get_session_history, and pending during the life cycle of RunnableWithMessageHistory.

So, it's impossible to use it in a "singleton" approach.

With langserv, you must declare the API with

add_routes(
    app,
    chain,
    path="/",
)

You must have a global variable chain.

chat_chain = RunnableWithMessageHistory(
    _context_and_question | retriever_chain,
    get_session_history=get_session_history, # <-- here
    input_messages_key="question",
    history_messages_key="chat_history",
)

The get_session_history cannot be async. The PostgresChatMessageHistory.async_connection() can not be used.

PostgresChatMessageHistory must be used if the singleton form, to be use with langserv. The engine must be set, without connection.

Originally created by @pprados on GitHub (Apr 25, 2024). The constructor of `PostgresChatMessageHistory` accepts only sync or async connection, and not an Engine. First, the connection was open in get_session_history, and pending during the life cycle of `RunnableWithMessageHistory`. So, it's impossible to use it in a "singleton" approach. With langserv, you must declare the API with ``` add_routes( app, chain, path="/", ) ``` You must have a global variable `chain`. ``` chat_chain = RunnableWithMessageHistory( _context_and_question | retriever_chain, get_session_history=get_session_history, # <-- here input_messages_key="question", history_messages_key="chat_history", ) ``` The `get_session_history` cannot be async. The `PostgresChatMessageHistory.async_connection()` can not be used. `PostgresChatMessageHistory` must be used if the singleton form, to be use with langserv. The engine must be set, without connection.

yindo commented

2026-02-16 05:16:03 -05:00

@eyurtsev commented on GitHub (Apr 29, 2024):

I'm hoping to avoid using too much SQLAlchemy. Would a psycopg pool object work for your use case?

@eyurtsev commented on GitHub (Apr 29, 2024): I'm hoping to avoid using too much SQLAlchemy. Would a psycopg pool object work for your use case?

yindo commented

2026-02-16 05:16:03 -05:00

@pprados commented on GitHub (May 21, 2024):

Yes. The idea is to use the same approach as for the other integrations with sqlalchemy, exploiting the connection pool and sharing sessions if possible.

the vectorstore proposes

        connection: Union[None, DBConnection, Engine, AsyncEngine, str] = None,

I think this is preferable and usable.

@eyurtsev , I can propose a PR for that, I can propose a PR for this, but I don't want it to remain on hold for several weeks, as with my other PRs.

@pprados commented on GitHub (May 21, 2024): Yes. The idea is to use the same approach as for the other integrations with sqlalchemy, exploiting the connection pool and sharing sessions if possible. the vectorstore proposes ``` connection: Union[None, DBConnection, Engine, AsyncEngine, str] = None, ``` I think this is preferable and usable. @eyurtsev , I can propose a PR for that, I can propose a PR for this, but I don't want it to remain on hold for several weeks, as with my other PRs.

yindo commented

2026-02-16 05:16:03 -05:00

@pprados commented on GitHub (May 23, 2024):

@eyurtsev
I propose a PR to resolve this problem.

@pprados commented on GitHub (May 23, 2024): @eyurtsev I propose a [PR](https://github.com/langchain-ai/langchain/pull/22065) to resolve this problem.

yindo commented

2026-02-16 05:16:03 -05:00