Critique the following blog post which explains how existing consensus algorithms fail under certain partial connectivity network conditions while a new consensus algorithm OmniPaxos doesn’t. The audience is expected to be technical but not necessarily informed about the intricacies of consensus. The text is meant to be clear, concise, and easy to understand.

Here is the first part of the blog post:
# Solving Partial connectivity with OmniPaxos
Consensus algorithms play a crucial role in maintaining fault-tolerant distributed systems. Notable examples are etcd’s use of Raft and Zookeeper’s use of Zab. The reliability of these systems is due to their ability to handle network failures as long as a majority of servers remain functional. However, as demonstrated by the 2020 Cloudflare outage, these consensus algorithms struggle to cope with certain network conditions, such as partial connectivity. In this article, we will explore what partial connectivity is, why existing algorithms fail under such conditions, and how OmniPaxos addresses this issue.

## Partial connectivity and leader locks
In order to function, consensus algorithms elect a server to be a leader and orchestrate the next steps of the algorithm. This leader must be able to communicate with a quorum (a majority) of other servers to make progress. Therefore, consensus algorithms run leader election processes which attempt to elect a server which is connected to a quorum of servers. 

Network errors which render an algorithm unable to elect a leader cannot make progress. Partial connectivity is a type of network failure where two servers are disconnected while both are still reachable by a third server. These kinds of network errors can lead to situations in which existing algorithms are unable to designate a stable leader, even when a server connected to a quorum of other servers could make progress if elected.

We can use the leader election process of Raft to examine how partial connectivity affects elections. The 4 main ideas behind Raft’s election process are:
A server becomes the leader by receiving a quorum of votes from other servers. 
If a server cannot communicate with its leader it calls for a new election with a higher term number. 
If the leader detects a server with a higher term number it steps down as leader. 
Servers only vote for servers which are more up-to-date than themselves.

Three scenarios – the Quorum-loss, Constrained-election, and Chained scenarios – illustrate the challenges that existing consensus algorithms face when confronted with partial connectivity.

[Quorum lost image here]

In the Quorum-loss scenario, the leader (server C) loses connectivity to the quorum. Server A is the only server that remains quorum-connected and able to make progress as a leader. Servers B, D, and E detect that they lost connection to their leader C and initiate a new election with a higher term number. Eventually, server A is elected leader when its election term surpasses C’s. However, there is a race for A to become elected before B, D, or E trigger the next election round. The randomized timers in Raft may cause the other servers to continuously disrupt elections and prevent the quorum-connected server A from being elected.

[Constrained election image here]
The Constrained-election scenario is similar to the Quorum-loss scenario, but the leader is entirely isolated from the rest, and servers B and D have a more up-to-date log than A. The network is again in a position where A must become the leader to make progress. However in this case, A cannot be elected as its log is outdated.

[Chained scenario image here]

In the Chained scenario, leader B loses connectivity to server C, but a chain of connections through other servers still exists to C. Since C is disconnected from B, it will call for a re-election with a higher term number and become the leader. If B then learns from A’s term number that the leadership has changed, the described scenario will recur in the reversed direction; B
will call for a new election with an even higher term number and regain leadership. This results in a livelock where the leader repeatedly changes due to a higher term number being gossiped. 

OmniPaxos is the only consensus algorithm that addresses all these scenarios. It does so by incorporating three key observations regarding the failure of existing algorithms in the three partial connectivity scenarios.

Quorum-Loss: The leader’s alive-status alone is insufficient to determine leader change; the leader must also be quorum-connected.
Constrained Election:Leader election must have no strict requirements on servers apart from quorum-connectivity.
Chained: Gossiping the identity of the current leader can cause liveness issues.