Idempotence by example: <i>Looking up some customer's name and address in a database are typically idempotent (in fact nullipotent), since this will not cause the database to change. Similarly, changing a customer's address is typically idempotent, because the final address will be the same no matter how many times it is submitted. However, placing an order for a car for the customer is typically not idempotent, since running the method/call several times will lead to several orders being placed. Canceling an order is idempotent, because the order remains canceled no matter how many requests are made.</i><p><a href="https://en.wikipedia.org/wiki/Idempotence" rel="nofollow">https://en.wikipedia.org/wiki/Idempotence</a>
Knowing the Raft[0][1] protocol, I felt this post was disingenuous going on for its entire length, and only mentioning Raft basically as a footnote, w/ no other references.<p>I think Raft deserves a bit more prominence and credit here, Antirez.<p><pre><code> [0] (pdf) https://ramcloud.stanford.edu/wiki/download/attachments/11370504/raft.pdf
[1] I kept reading thinking to myself repeatedly "This is just Raft".</code></pre>
It looks like the protocol is broken; can anyone confirm?<p>Suppose a handful of the processes trigger an election simultaneously, each with a `currentEpoch` of `n`, so that each process has voted but no proposal has a majority. Now all processes have a `lastVoteEpoch` of `n`.<p>According to the description, no process will vote more than once in a single epoch. However, a process will can only propose a new value using its `currentEpoch`. Since each proposal must have a `currentEpoch` of `n`, but no process is still allowed to vote in that epoch, no more state transitions are possible and the frequency cannot change.