MemorySaver ignores newVersions argument on put - not storing deltas

[benjamincburns]

Found while working on #541. Per discussion on #577, MemorySaver isn't respecting the newVersions argument, and as a result it's storing the entire contents of checkpoint.channel_values on every call.

[trollboss2572]

Good morning, we are a group of students at the University of Toronto currently investigating the issue mentioned and believe that we could help tackle this. Can we get this opened as an issue and assigned to me? @jacoblee93

[benjamincburns]

@trollboss2572 I discussed this briefly with @nfcampos the other day, and I think there's an open question as to whether or not this is a valid issue.

The newVersions argument on put can be optionally used by checkpointers to determine which channels have updated state since the previous checkpoint. This allows storage backends to avoid storing duplicate state for channels that haven't changed since the previous checkpoint. In the case of MemorySaver, there's a valid argument that this isn't a worthwhile optimization.

In my opinion, whether or not this is an issue boils down to whether the LangGraph team wants MemorySaver to serve as a reference implementation for checkpointer authors to follow. If so, then it would make sense to implement versioned channel storage, as otherwise MemorySaver would be an incomplete reference.

Furthermore, if the LangGraph team decide that MemorySaver should stay as-is, then the test in @langchain/langgraph-checkpoint-validation that validates versioned channel storage should either be removed, or more ideally, moved to an "optional" suite that only runs when the user explicitly requests tests for optimizations.

[trollboss2572]

@benjamincburns Thank you for the swift response to my message.

While I was researching the codebase I came to the same conclusion. This is more of an architectural issue than an implementation issue/feature/bug, so I believe this would be above my pay grade and would be more suited to the maintainers of langgraph to see what option they would prefer, as you mentioned.

I read your other post and saw your recommendations for implementing CheckpointSaver for a different database framework, I believe that might be the best bet if we were to implement something. Thank you for your advice on that.

Thank you for your time and for being open to questions should they arise. If there is anything that can be done by volunteers regarding the architectural updates to MemorySaver though, let me know.

[benjamincburns]

@trollboss2572 no worries, happy to help. Though just a reminder, I'm a volunteer just like you, so your guess is roughly as good as mine :-)