zeekayandHanzo Dev 8faefad938 atomic: Apply is NOT idempotent — say so, and prove it ...

atomiczap.Apply's doc claimed a replayed window is a harmless no-op, so a
caller could apply first and advance its flushed-seq marker after. That is
false, and a caller that believes it halts its chain.

chains/atomic/state.go: SetValue on a present key returns errDuplicatePut,
which is fatal on an accept path. Worse, SetValue on a key the peer has
already CONSUMED succeeds and re-creates the object, so the peer can be
funded twice. RemoveValue's behaviour is not uniform either — replaying the
consume of a real object is tolerated, replaying one of a never-present key
errors on the tombstone.

Corrects the comment to state what a cross-process caller must actually do
(commit state first, accept at-most-once) and adds the tests that pin all
three behaviours, so the next person to reach for at-least-once has to
delete a passing test to do it.

Co-authored-by: Hanzo Dev <[email protected]>

2026-08-07 06:36:50 -07:00

..

atomiczap_test.go

…

atomiczap.go

atomic: Apply is NOT idempotent — say so, and prove it

2026-08-07 06:36:50 -07:00