FA-75114 / CRDT convergence / Member archive

Epoch-resettable counter: every reset reuses epoch one · case 04

A second reset is lost because it does not open a newer epoch than the first.

Member previewVariant 4 · 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
second reset opens a new epoch	`{"epochs": [1, 0, 1], "values": [1, 0, 1]}`	`{"epochs": [2, 0, 2], "values": [1, 0, 1]}`	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.