В Towards AI описали проблемы LangGraph checkpointing после запуска в production
Checkpointing в LangGraph может создавать проблемы в production, хотя через PostgresSaver всё настраивается довольно просто. Как пишет Towards AI, после обновления схемы состояния графа старые потоки выполнения иногда перестают нормально восстанавливаться. Причина в том, что LangGraph не делает миграции checkpoint-данных автоматически, а несовместимые изменения в TypedDict могут вызывать ошибки при возобновлении работы.
В статье объясняется, что система сохраняет полное состояние графа на каждой границе узла. Туда входят ключи TypedDict, ожидающие задачи и позиция выполнения. Все данные записываются в Postgres с парой идентификаторов thread_id и checkpoint_id. Такой подход нужен для восстановления после сбоев, сценариев human-in-the-loop и воспроизведения предыдущих состояний графа.
Автор отдельно перечисляет несколько проблем, связанных с эксплуатацией. Поведение interrupt_before и interrupt_after называют неопределённым при параллельном выполнении subgraph с fan-out. Также thread-scoped checkpointing неудобен для multi-tenant систем, если нет отдельной схемы индексации и соглашений по именованию.
В материале приводится пример, где таблица checkpoint в Postgres выросла до 40 ГБ за шесть недель, потому что не была настроена политика хранения данных. Ещё один момент касается MemorySaver: он не воспроизводит ошибки сериализации, из-за чего различия между dev и production могут скрывать реальные сбои.
Ключевые факты
LangGraph сохраняет полное состояние графа в Postgres на каждой границе узла
Checkpoint-данные хранятся с привязкой к thread_id и checkpoint_id
Изменения схемы TypedDict могут ломать восстановление старых потоков без предупреждений и автоматических миграций
В одном из примеров таблица checkpoint выросла до 40 ГБ за шесть недель без политики retention