Split out of the #223 review (raised by Codex on #234): followers validate every replica append against their statically configured fencing_epoch, and nothing on a follower watches metadata. On a replicated range with a lease-driven leader, the first grant whose epoch differs from the followers' configuration fences the leader out of its own quorum.
Current state:
What closing it needs:
- A follower-side loop that observes committed range-lease state (linearizable read on the admin transport, same client as the lease agent, or a cheaper watch primitive) and drives the follower's
MetaFencingEpoch/held epoch monotonically.
- The follower must fail closed while its view is stale — the current behaviour (reject unknown epochs) is the safe half; the missing half is learning new epochs without a restart.
- Scenario 09 should then drop its epoch-seeding/restart workaround; the
EXPECTED_FIRST_EPOCH assertion and the follower-restart block are the markers to delete.
Also unblocks replicated ranges under co-located nodes (#215 / scenario 10 currently pins the colocated data role to standalone for exactly this reason).
Split out of the #223 review (raised by Codex on #234): followers validate every replica append against their statically configured
fencing_epoch, and nothing on a follower watches metadata. On a replicated range with a lease-driven leader, the first grant whose epoch differs from the followers' configuration fences the leader out of its own quorum.Current state:
MetaFencingEpochfrom metadata; followers have no equivalent.vtop-nodewarns at startup whenleaseis configured on a replicated leader, and the config docs state the limitation.What closing it needs:
MetaFencingEpoch/held epoch monotonically.EXPECTED_FIRST_EPOCHassertion and the follower-restart block are the markers to delete.Also unblocks replicated ranges under co-located nodes (#215 / scenario 10 currently pins the colocated data role to standalone for exactly this reason).