Fault injection · correctness verification
Raft under chaos
Composable fault injection and per-tick correctness verification against a Raft consensus implementation, driven externally through a queued transport built on its own node API.
Verdict
Method
What is checked, and what is not
Four properties are asserted on every tick rather than at the end of a run, so the report can say when something broke rather than only that the final state looked healthy. A violation that appears and then heals still counts.
A write counts as acknowledged only once the leader's
commit_index covers it — the moment a real server would answer the client. An uncommitted
entry disappearing is correct Raft behaviour and is recorded as an overwrite, never as a loss.
Stale reads from followers are deliberately not treated as violations. The engine documents that reads are served locally with no read-index or leader lease, so a lagging follower returning an old value is designed behaviour rather than a defect.
Findings
Scenarios
What was injected, and what happened
Timelines run left to right in simulation ticks. Cyan bands are leadership, hatched red bands are active faults, and the pulsing dot marks the instant a fault was injected.