🤖 This issue was generated by Claude on behalf of @keddie.
A §3.10 spec-conformance audit (Ongaro dissertation §3.10 / §4.2.3), run against the freshly-decomposed LeadershipTransferMachine (#1227) treating the pre-existing logic as unproven, found 5 conformance bugs. All pre-existing (the extraction preserved them faithfully; behavior-preservation review passed). Same approach that found the snapshot bugs in #1218.
Severity note: unlike #1218 (which risked committed-entry loss), these are liveness / false-success, NOT safety — Leader Completeness is intact (the §5.4.1 vote-intersection argument holds; matchIndex >= commitIndex guarantees the target has all committed entries). So they're real correctness/contract bugs but not data-loss-urgent.
| Sub |
Severity |
One-liner |
| B-1 |
🟠 liveness |
TimeoutNow gated on commitIndex, not lastLogIndex → premature TimeoutNow to a not-fully-caught-up target; transfer fails but reports success. |
| B-2 |
🟠 liveness |
Vote-stickiness disrupt-permission is missing from the wire RequestVote → in clusters ≥4 the target's first election is denied by lease-holding voters. |
| B-3 |
🟠 contract |
Transfer "success" completes on ANY higher-term step-down, before/regardless of the target actually winning → caller told success when leadership may bounce back. |
| B-4 |
🟡 latent |
Stale auto-timeout has no generation check → under a real dispatcher a late TransferTimeout can abort the NEXT transfer. |
| B-5 |
🟡 liveness |
§3.10 step 1 gates propose/Forward but NOT membership changes → a config change mid-transfer grows the log the target is matching. |
Spec: dissertation §3.10 steps 1–5 (stop serving → fully update target's log → TimeoutNow → target campaigns at higher term → old leader steps down on target's win) + §4.2.3 (disrupt-permission flag). B-1 is load-bearing; B-2/B-3 compound it into user-visible false successes. A ≥4-voter transfer test would have caught B-2. Per-bug detail in the sub-issues.
A §3.10 spec-conformance audit (Ongaro dissertation §3.10 / §4.2.3), run against the freshly-decomposed
LeadershipTransferMachine(#1227) treating the pre-existing logic as unproven, found 5 conformance bugs. All pre-existing (the extraction preserved them faithfully; behavior-preservation review passed). Same approach that found the snapshot bugs in #1218.Severity note: unlike #1218 (which risked committed-entry loss), these are liveness / false-success, NOT safety — Leader Completeness is intact (the §5.4.1 vote-intersection argument holds;
matchIndex >= commitIndexguarantees the target has all committed entries). So they're real correctness/contract bugs but not data-loss-urgent.commitIndex, notlastLogIndex→ premature TimeoutNow to a not-fully-caught-up target; transfer fails but reports success.RequestVote→ in clusters ≥4 the target's first election is denied by lease-holding voters.TransferTimeoutcan abort the NEXT transfer.propose/Forwardbut NOT membership changes → a config change mid-transfer grows the log the target is matching.Spec: dissertation §3.10 steps 1–5 (stop serving → fully update target's log → TimeoutNow → target campaigns at higher term → old leader steps down on target's win) + §4.2.3 (disrupt-permission flag). B-1 is load-bearing; B-2/B-3 compound it into user-visible false successes. A ≥4-voter transfer test would have caught B-2. Per-bug detail in the sub-issues.