Hi, as far as I can see, the AsyncShallowPostgresSaver will be depretiated in the future versions, with a recommendations to:
>“Use AsyncPostgresSaver instead, and invoke the graph with await graph.ainvoke(..., durability='exit').”,
But as far as I understand, this is not an equivalent replacement. Using durability='exit' will disable a lot of nice features (like using interrupts) and make the whole thing… Not durable at all!
Is there still an option to have both:
Durable execution (interrupts, saving state after each node)#
Only saving the latest version of the state (no time-travel)
Changes are persisted only when graph execution completes (either successfully or with an error). This provides the best performance for long-running graphs but means intermediate state is not saved, so you cannot recover from mid-execution failures or interrupt the graph execution.
Even if the exit durability setting covers interrupts (which the docs indicate otherwise), there really should be a mechanism to cap the number of checkpoints that are persisted. Only 1 makes sense, and N of them would be even more generalised.
When used in production, the default setup gets out of hand pretty quickly, meaning either:
not using the checkpointer/saver, and dealing with persistence and interrupts manually