anchor.diff:  improvements throughout this page to provide the full context.
   
   If you’re interested in more on how we approach ensuring resiliency in
  -Elasticsearch, you may be interested in Igor Motov’s recent talk
  +Elasticsearch, you may be interested in Igor Motov’s talk
   http://www.elastic.co/videos/improving-elasticsearch-resiliency[Improving Elasticsearch Resiliency].
   
   You may also be interested in our blog post
  
positive.code: The new tests are run continuously in our testing farm and are passing. We are also working on running Jepsen independently to verify
  that no failures are found.
  
  [float]
  === Replicas can fall out of sync when a primary shard fails (STATUS: ONGOING)
  
  When a primary shard fails, a replica shard will be promoted to be the
  primary shard. If there is more than one replica shard, it is possible
  for the remaining replicas to be out of sync with the new primary
  shard. This is caused by operations that were in-flight when the primary
  shard failed and may not have been processed on all replica
  shards. Currently, the discrepancies are not repaired on primary
  promotion but instead would be repaired if replica shards are relocated
  (e.g., from hot to cold nodes); this does mean that the length of time
  which replicas can be out of sync with the primary shard is
  unbounded. Sequence numbers {GIT}10708[#10708] will provide a mechanism
  for syncing the remaining replicas with the newly-promoted primary
  shard.
  
  == Completed
  
  [float]
  === Repeated network partitions can cause cluster state updates to be lost (STATUS: DONE, v7.0.0)
  
negative.code: Other safeguards are tracked in the meta-issue {GIT}11511[#11511].
  
  [float]
  === Relocating shards omitted by reporting infrastructure (STATUS: ONGOING)
  
  Indices stats and indices segments requests reach out to all nodes that have shards of that index. Shards that have relocated from a node
  