Topic/NamedBarrierValue from_checkpoint aliases the checkpoint container instead of copying

[vidigoat]

Description

Topic.from_checkpoint and NamedBarrierValue.from_checkpoint assign the checkpoint's container directly to the new channel instead of copying it:

# topic.py
empty.values = checkpoint
# named_barrier_value.py
empty.seen = checkpoint

BaseChannel.from_checkpoint documents that "If the checkpoint contains complex data structures, they should be copied", and the channels' own copy() methods do copy (self.values.copy(), self.seen.copy()), but from_checkpoint does not. So two channels restored from the same checkpoint object share the same list/set, and an in-place update to one mutates the checkpoint and the sibling.

Reproduction

from langgraph.channels.topic import Topic

source = Topic(str, accumulate=True)
source.update(["a", "b"])
checkpoint = source.checkpoint()

one = Topic(str, accumulate=True).from_checkpoint(checkpoint)
two = Topic(str, accumulate=True).from_checkpoint(checkpoint)
one.update(["c"])

print(two.get())     # ['a', 'b', 'c']  -> expected ['a', 'b']
print(checkpoint)    # ['a', 'b', 'c']  -> checkpoint was mutated

NamedBarrierValue (and NamedBarrierValueAfterFinish) behave the same way with their seen set. This matters when a single loaded checkpoint is reused across restores (replay / forking a thread): an accumulate=True topic or a barrier value can retroactively corrupt the persisted checkpoint.

Expected

from_checkpoint should copy the container, like copy() already does, so restored channels are independent of the checkpoint and of each other.

System info

langgraph main; the affected code is in langgraph/channels/topic.py and langgraph/channels/named_barrier_value.py.

[vidigoat]

I'd like to work on this; could a maintainer assign it to me? I have a fix ready (copy the container in from_checkpoint for Topic and NamedBarrierValue, matching copy() and the BaseChannel contract) with regression tests, and will open the PR once assigned per the contribution flow.

[sharb1235-hash]

This is a textbook example of why in-memory checkpointing can be risky for long-running agent workflows. When an active run accidentally mutates your historical snapshots via reference aliasing, time-travel debugging completely breaks. I built an open-source, local-first alternative called Attow Nexus (https://github.com/sharb1235-hash/attow-nexus) to solve this. It runs as an out-of-process Rust daemon that writes state transitions directly to an on-disk SQLite WAL database. Because the ledger is completely isolated from the runtime memory space, active Python bugs can never retroactively corrupt your historical commit history.

[vidigoat]

I have a fix ready for this (PR #7993, which the bot auto-closed since I wasn't assigned). The root cause is that Topic.from_checkpoint and NamedBarrierValue.from_checkpoint assign the checkpoint container directly (empty.values = checkpoint / empty.seen = checkpoint) instead of copying it, so a restored channel aliases the saved snapshot and later mutations corrupt history. The fix is a one-line .copy() in each, with regression tests in tests/test_channels.py.

Could a maintainer assign this issue to me so I can reopen the PR per the contribution process? Happy to rebase onto latest main. Thanks!