LangGraph PostgresStore short TTL expires after a read

A memory item meant to live for seconds can disappear immediately after being read. An open LangGraph report reproduces this with PostgresStore, refresh_on_read=True, and a 0.25-minute TTL. The issue says a read rounds the stored TTL minutes to an integer, causing the refreshed expiry to be effectively now for a TTL of 30 seconds or less. That is a reported version-specific behavior, not a universal limit on agent memory.

Reproduce with a safe test item

Create a disposable store namespace and put a test item with a short TTL. Read it, inspect the persisted TTL and expiry, wait briefly, sweep expired items, and read again. Compare that sequence with a control item that is never read. The LangGraph persistence guide distinguishes a cross-thread store from a thread checkpointer; ensure the affected feature really uses PostgresStore.

Avoid relying on accidental refresh

Until the deployed version is verified, use a TTL comfortably above the problematic range or explicitly write a fresh item with a tested expiry contract. A longer TTL changes data-retention behavior, so review privacy and deletion requirements before applying it. Do not turn off expiry just to keep a workflow green. If memory is business critical, test expiry boundaries at 15, 30, 31, and 60 seconds in the same database schema used in production.

Check the user-visible consequence

If an item vanishes mid-conversation, the agent may ask for information again or act without the expected context. Log missing-item events without exposing stored content, and define a safe fallback when memory is unavailable. Require a migration and regression test before changing a production store column.

Adovo’s view

Memory duration is part of the product promise. A read that shortens life instead of extending it is a contract failure. Test the boundary in the database, not just in an in-memory mock.