FA-75102 / CRDT convergence / Member archive

Epoch-resettable counter: a newer epoch is merged into pre-reset slots · case 02

Increments made before a reset reappear after the reset propagates.

Member previewVariant 2 · 3 implementations · 8 checks per implementation

Case contract

Each replica holds an epoch and grow-only slots for that epoch. ["inc", r, k] grows r's slot; ["reset", r] increments r's epoch and clears all its slots. ["sync", s, d]: if s's epoch is higher, d adopts s's epoch and a copy of s's slots; if equal, slots merge by maximum; if lower, nothing changes. Return values (sum of slots) and epochs.

Why this case matters

Reset-wins counters need an epoch so a reset is not undone by increments that were concurrent with it.

One recorded failure

Sample boundary fixture

This sample comes from the broken implementation of a controlled reproducer.

Boundary fixture	Actual	Expected	Outcome
reset wins over concurrent older increments	`{"epochs": [1, 1, 0], "values": [4, 4, 0]}`	`{"epochs": [1, 1, 0], "values": [0, 0, 0]}`	Failed

MEMBER ARCHIVE

The complete case is available to members.

This record includes three runnable implementations, regression fixtures, execution results, and source hashes.

Member access is invitation-based. Sign in with your invited account to inspect the sources.