Downgrading Consistency Retry Policy

The Downgrading Consistency retry policy retries failed queries with a lower consistency level than the one initially requested.

BEWARE: By doing so, it may break consistency guarantees. In other words, if you use this retry policy, there are cases where a read at QUORUM may not see a preceding write at QUORUM. Do not use this policy unless you have understood the cases where this can happen and are ok with that.

Downgrading Consistency policy is used explicitly

Given
a running cassandra cluster with schema:
CREATE KEYSPACE simplex WITH replication = {'class': 'SimpleStrategy', 'replication_factor': 3};
USE simplex;
CREATE TABLE songs (
  id uuid PRIMARY KEY,
  title text,
  album text,
  artist text,
  tags set<text>,
  data blob
);
INSERT INTO songs (id, title, album, artist, tags)
VALUES (
   756716f7-2e54-4715-9f00-91dcbea6cf50,
   'La Petite Tonkinoise',
   'Bye Bye Blackbird',
   'Joséphine Baker',
   {'jazz', '2013'})
;
INSERT INTO songs (id, title, album, artist, tags)
VALUES (
   f6071e72-48ec-4fcb-bf3e-379c8a696488,
   'Die Mösch',
   'In Gold',
   'Willi Ostermann',
   {'kölsch', '1996', 'birds'}
);
INSERT INTO songs (id, title, album, artist, tags)
VALUES (
   fbdf82ed-0063-4796-9c7c-a3d4f47b4b25,
   'Memo From Turner',
   'Performance',
   'Mick Jager',
   {'soundtrack', '1991'}
);
And
the following example:
require 'cassandra'

cluster = Cassandra.cluster(retry_policy: Cassandra::Retry::Policies::DowngradingConsistency.new)
session = cluster.connect('simplex')
result  = session.execute('SELECT * FROM songs', consistency: :all)

puts "actual consistency: #{result.execution_info.consistency}"
When
node 3 stops
And
it is executed
Then
its output should contain:
actual consistency: quorum