Production compiles the graph without a checkpointer when the Postgres pool fails

[M1ndSmith]

_get_connection_pool() catches a Postgres failure in production, logs continuing_without_connection_pool, and returns None. create_graph() then sets checkpointer=None and compiles.

/messages, clear_chat_history, and HITL Command(resume=...) read AsyncPostgresSaver (checkpoint tables, thread_id). mem0 search/add write user facts to pgvector. Same database, two stores.

Expected: the process refuses to serve, or /health returns 503, if the checkpointer cannot be created.

I have not runtime-reproduced this. The branch is in app/core/langgraph/graph.py (_get_connection_pool, create_graph).

[wassim249]

Fixed in #98 — thank you for this, it was a genuinely good catch.

You flagged it as not runtime-reproduced, so I reproduced it before fixing. In production with a pool that fails to construct, master did exactly what you described:

warning  continuing_without_connection_pool  environment=production
info     graph_created  has_checkpointer=False  environment=production

It compiled and served with checkpointer=None, and /health still reported healthy — so history and HITL resume were being dropped silently, with nothing surfacing the outage. Your reading of _get_connection_pool / create_graph was correct on both counts.

Testing also turned up a second variant you couldn't have seen from the source: if the pool constructs but the database is unreachable, open() doesn't block, so the failure lands later at checkpointer.setup(). On master that hit the outer handler, logged continuing_without_graph, returned None, and every request then died on a bare RuntimeError — again with /health green.

The fix takes your "refuse to serve" option: the failure now propagates in every environment, and the return types are tightened to non-Optional so the None path can't be reintroduced.