Summary
The session-store quorum currently persists exact consensus identity, configuration epoch, member bindings, Recovery state, and Openraft state. It does not yet provide a reusable proof that only one live process can participate as a particular voter when durable storage and voter credentials are cloned or a live database path is replaced.
This is distinct from physical placement resilience and from the fixed-quorum readiness separation in #656.
Adversarial finding
An attempted local SQLite anchor based on a database-row plus flock and st_dev/st_ino/path hashes was rejected during review:
- a live path replacement can leave the old process on one inode while a new process opens another inode under the same path;
- device/inode values can change across a legitimate Kubernetes PVC remount and are not globally unique;
- a copied database also copies any DB-resident anchor;
- a local-only anchor gives peers no authoritative incarnation roster;
- trait-reported peer scope alone is not a proof of the authenticated process incarnation;
- an ordinary constructor must not be able to downgrade a fixed-authority database.
The rejected design must not be revived as a production guarantee.
Required reusable contract
Design a product-neutral fixed-voter incarnation boundary that does not depend on a continuously available controller or Kubernetes API:
- persist an immutable local voter genesis binding and a quorum-authoritative exact voter-incarnation roster;
- make fixed-mode storage non-downgradable through ordinary constructors;
- bind inbound and outbound authenticated consensus RPC admission to the exact voter, consensus epoch, and active incarnation;
- fence Vote, replication, snapshot, application mutation, and readiness paths on incarnation loss;
- serialize replacement by a quorum-managed incarnation handoff or another authoritative non-copyable backing capability;
- preserve the local binding across snapshot installation and require explicit Recovery for ambiguous replacement;
- keep all failures bounded and value-free.
Filesystem path, device, inode, caller descriptor, Pod UID, or image digest alone must not be treated as permanent voter identity.
Acceptance evidence
- two OS processes with one voter identity cannot both participate or obtain authority;
- live path replacement, blank replacement, copied database, hardlinks, and ordinary-constructor downgrade fail closed;
- a legitimate same-PVC restart/remount retains authority without a controller/API call;
- stale process traffic and Raft RPCs are rejected after handoff;
- snapshot install cannot overwrite local incarnation authority;
- exact 3/5 membership, majority loss, Recovery latch, and value-free diagnostics remain intact;
- fault injection covers every incarnation CAS/readback and ambiguous response.
Relationship to #656
#656 should use the SDK's existing persisted consensus scope, Recovery latch, authenticated member bindings, and fresh linearizable majority barrier while separating physical placement reporting. It must not claim this stronger anti-clone/incarnation guarantee until this issue is implemented.
Summary
The session-store quorum currently persists exact consensus identity, configuration epoch, member bindings, Recovery state, and Openraft state. It does not yet provide a reusable proof that only one live process can participate as a particular voter when durable storage and voter credentials are cloned or a live database path is replaced.
This is distinct from physical placement resilience and from the fixed-quorum readiness separation in #656.
Adversarial finding
An attempted local SQLite anchor based on a database-row plus
flockandst_dev/st_ino/path hashes was rejected during review:The rejected design must not be revived as a production guarantee.
Required reusable contract
Design a product-neutral fixed-voter incarnation boundary that does not depend on a continuously available controller or Kubernetes API:
Filesystem path, device, inode, caller descriptor, Pod UID, or image digest alone must not be treated as permanent voter identity.
Acceptance evidence
Relationship to #656
#656 should use the SDK's existing persisted consensus scope, Recovery latch, authenticated member bindings, and fresh linearizable majority barrier while separating physical placement reporting. It must not claim this stronger anti-clone/incarnation guarantee until this issue is implemented.