Migrating from AsyncShallowPostgresSaver

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:

  1. Durable execution (interrupts, saving state after each node)#
  2. Only saving the latest version of the state (no time-travel)
1 Like

Interrupts still work with exit!

Good to know!

I had this false impression due to this line in documentation:

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.

Still, I’d like to know if there’s an option to have:

  1. sync level durability
  2. save only the latest state
1 Like

Sorry to bother, but are there any suggestions to the issue described?

1 Like

Similarly interested in updates :eye:

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:

  1. not using the checkpointer/saver, and dealing with persistence and interrupts manually
  2. manually cleaning old checkpoints