anchor.diff:  This status page is a start, but we can do a better job of explicitly documenting the processes at work in Elasticsearch, and what happens in the case of each type of failure. The plan is to have a test case that validates each behavior under simulated conditions. Every test will document the expected results, the associated test code and an explicit PASS or FAIL status for each simulated case.
   
   [float]
  -=== Do not allow stale shards to automatically be promoted to primary (STATUS: ONGOING)
  -
  -In some scenarios, after the loss of all valid copies, a stale replica shard can be assigned as a primary. This can lead to
  -a loss of acknowledged writes if the valid copies are not lost but are rather temporarily isolated. Work is underway
  -({GIT}14671[#14671]) to prevent the automatic promotion of a stale primary and only allow such promotion to occur when
  -a system operator manually intervenes.
  +=== Do not allow stale shards to automatically be promoted to primary (STATUS: ONGOING, v3.0.0)
  +
  +In some scenarios, after the loss of all valid copies, a stale replica shard can be automatically assigned as a primary, preferring old data
  +to no data at all ({GIT}14671[#14671]). This can lead to a loss of acknowledged writes if the valid copies are not lost but are rather
  +temporarily unavailable. Allocation IDs ({GIT}14739[#14739]) solve this issue by tracking non-stale shard copies in the cluster and using
  +this tracking information to allocate primary shards. When all shard copies are lost or only stale ones available, Elasticsearch will wait
  +for one of the good shard copies to reappear. In case where all good copies are lost, a manual override command can be used to allocate a
  +stale shard copy.
  +
  +[float]
  +=== Make index creation resilient to index closing and full cluster crashes (STATUS: ONGOING, v3.0.0)
  +
  +Recovering an index requires a quorum (with an exception for 2) of shard copies to be available to allocate a primary. This means that
  +a primary cannot be assigned if the cluster dies before enough shards have been allocated ({GIT}9126[#9126]). The same happens if an index
  +is closed before enough shard copies were started, making it impossible to reopen the index ({GIT}15281[#15281]).
  +Allocation IDs ({GIT}14739[#14739]) solve this issue by tracking allocated shard copies in the cluster. This makes it possible to safely
  +recover an index in the presence of a single shard copy. Allocation IDs can also distinguish the situation where an index has been created
  +but none of the shards have been started. If such an index was inadvertently closed before at least one shard could be started, a fresh
  +shard will be allocated upon reopening the index.
  +
  +== Unreleased
  +
  +[float]
  +=== Use two phase commit for Cluster State publishing (STATUS: UNRELEASED, v3.0.0)
  +
  +A master node in Elasticsearch continuously https://www.elastic.co/guide/en/elasticsearch/reference/current/modules-discovery-zen.html#fault-detection[monitors the cluster nodes]
  +and removes any node from the cluster that doesn't respond to its pings in a timely
  +fashion. If the master is left with fewer nodes than the `discovery.zen.minimum_master_nodes`
  +settings, it will step down and a new master election will start.
  +
  +When a network partition causes a master node to lose many followers, there is a short window
  +in time until the node loss is detected and the master steps down. During that window, the
  +master may erroneously accept and acknowledge cluster state changes. To avoid this, we introduce
  +a new phase to cluster state publishing where the proposed cluster state is sent to all nodes
  +but is not yet committed. Only once enough nodes (`discovery.zen.minimum_master_nodes`) actively acknowledge
  +the change, it is committed and commit messages are sent to the nodes. See {GIT}13062[#13062].
   
   == Completed
   
  
positive.code: * Set a hard limit on `from`/`size` parameters {GIT}9311[#9311]. (STATUS: DONE, v2.1.0)
  * Prevent combinatorial explosion in aggregations from causing OOM {GIT}8081[#8081]. (STATUS: ONGOING)
  * Add the byte size of each hit to the request circuit breaker {GIT}9310[#9310]. (STATUS: ONGOING)
  
  [float]
  === Loss of documents during network partition (STATUS: ONGOING)
  
  If a network partition separates a node from the master, there is some window of time before the node detects it. The length of the window is dependent on the type of the partition. This window is extremely small if a socket is broken. More adversarial partitions, for example, silently dropping requests without breaking the socket can take longer (up to 3x30s using current defaults).
  
  If the node hosts a primary shard at the moment of partition, and ends up being isolated from the cluster (which could have resulted in {GIT}2488[split-brain] before), some documents that are being indexed into the primary may be lost if they fail to reach one of the allocated replicas (due to the partition) and that replica is later promoted to primary by the master. {GIT}7572[#7572]
  
  A test to replicate this condition was added in {GIT}7493[#7493].
  
  [float]
  === Jepsen Test Failures (STATUS: ONGOING)
  
negative.code: We are committed to tracking down and fixing all the issues that are posted.
  
  [float]
  === Better request retry mechanism when nodes are disconnected (STATUS: ONGOING)
  
  If the node holding a primary shard is disconnected for whatever reason, the
  