A simple distributed algorithm for small idempotent information

Idempotence by example: <i>Looking up some customer&#x27;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&#x27;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&#x2F;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:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;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&#x2F; no other references.<p>I think Raft deserves a bit more prominence and credit here, Antirez.<p><pre><code> [0] (pdf) https:&#x2F;&#x2F;ramcloud.stanford.edu&#x2F;wiki&#x2F;download&#x2F;attachments&#x2F;11370504&#x2F;raft.pdf [1] I kept reading thinking to myself repeatedly &quot;This is just Raft&quot;.</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.