mirror of
https://github.com/PerpetualSoftware/pad.git
synced 2026-09-22 10:33:27 +00:00
xarmian
47a83ccdd2
A class sweep over every knownFrom assignment found that the previous commit's +1 is a strict improvement and NOT the complete fix its comment implied. replaySince serves any cursor at or above knownFrom-1, so n.ID+1 admits n.ID itself — and if the old space also reached n.ID, that cursor is still ambiguous, as is every old-space id up to the old high water mark. The epoch arm's identical +1 has the same residual, and a subsequent GAP overwrites the boundary with the ordinary knownFrom = n.ID, which can lower it back into the overlap. No constant closes this. It needs a boundary that remembers the OLD space's extent — refuse everything at or below it until the new space climbs past — which is a resume-semantics change touching the epoch path too. Filed as BUG-2743 with that design (an ambiguousUntil field guarded in replaySince rather than more arithmetic per arm, which also fixes the gap-overwrite for free), and referenced from both the code and the test so neither reads as more than it is. The honest framing, now stated where the arm lives: this is mitigation. Two id spaces with overlapping integers cannot be told apart by arithmetic on those integers, which is exactly why redisWatchEpochSuffix exists. A counter reset with the epoch intact is the case the epoch cannot see. Claude-Session: https://claude.ai/code/session_01JVDBKbgn3Xt7ndW1YoYd8X