av9ash/GitBugs huggingface dataset:
Bug: SSLFactory should initialize SSLContext before setting protocols
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 17/Dec/20 22:36
Resolved: 03/Feb/21 03:16

Trying to use sstableloader from the latest trunk produced the following Exception:

{quote}
Exception in thread "main" java.lang.RuntimeException: Could not create SSL Context.
	at org.apache.cassandra.tools.BulkLoader.buildSSLOptions(BulkLoader.java:261)
	at org.apache.cassandra.tools.BulkLoader.load(BulkLoader.java:64)
	at org.apache.cassandra.tools.BulkLoader.main(BulkLoader.java:49)
Caused by: java.io.IOException: Error creating/initializing the SSL Context
	at org.apache.cassandra.security.SSLFactory.createSSLContext(SSLFactory.java:184)
	at org.apache.cassandra.tools.BulkLoader.buildSSLOptions(BulkLoader.java:257)
	... 2 more
Caused by: java.lang.IllegalStateException: SSLContext is not initialized
	at sun.security.ssl.SSLContextImpl.engineGetSocketFactory(SSLContextImpl.java:208)
	at javax.net.ssl.SSLContextSpi.getDefaultSocket(SSLContextSpi.java:158)
	at javax.net.ssl.SSLContextSpi.engineGetDefaultSSLParameters(SSLContextSpi.java:184)
	at javax.net.ssl.SSLContext.getDefaultSSLParameters(SSLContext.java:435)
	at org.apache.cassandra.security.SSLFactory.createSSLContext(SSLFactory.java:178)
	... 3 more
{quote}

I believe this is because of a change to SSLFactory for CASSANDRA-13325 here:

[https://github.com/apache/cassandra/commit/919a8964a83511d96766c3e53ba603e77bca626c#diff-0d569398cfd58566fc56bfb80c971a72afe3f392addc2df731a0b44baf29019eR177-R178]

 

I think the solution is to call {{ctx.init()}} before trying to call {{ctx.getDefaultSSLParameters()}}, essentialy swapping the two lines in the link above.
Bug: GROUP BY queries with paging can return deleted data
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 30/Nov/20 16:57
Resolved: 15/Feb/21 11:56

{{GROUP BY}} queries using paging and CL>ONE/LOCAL_ONE. This dtest reproduces the problem:
{code:java}
try (Cluster cluster = init(Cluster.create(2)))
{
    cluster.schemaChange(withKeyspace("CREATE TABLE %s.t (pk int, ck int, PRIMARY KEY (pk, ck))"));
    ICoordinator coordinator = cluster.coordinator(1);
    coordinator.execute(withKeyspace("INSERT INTO %s.t (pk, ck) VALUES (0, 0)"), ConsistencyLevel.ALL);
    coordinator.execute(withKeyspace("INSERT INTO %s.t (pk, ck) VALUES (1, 1)"), ConsistencyLevel.ALL);
    
    cluster.get(1).executeInternal(withKeyspace("DELETE FROM %s.t WHERE pk=0 AND ck=0"));
    cluster.get(2).executeInternal(withKeyspace("DELETE FROM %s.t WHERE pk=1 AND ck=1"));
    String query = withKeyspace("SELECT * FROM %s.t GROUP BY pk");
    Iterator<Object[]> rows = coordinator.executeWithPaging(query, ConsistencyLevel.ALL, 1);
    assertRows(Iterators.toArray(rows, Object[].class));
}
{code}
Using a 2-node cluster and RF=2, the test inserts two partitions in both nodes. Then it locally deletes each row in a separate node, so each node sees a different partition alive, but reconciliation should produce no alive partitions. However, a {{GROUP BY}} query using a page size of 1 wrongly returns one of the rows.

This has been detected during CASSANDRA-16180, and it is probably related to CASSANDRA-15459, which solved a similar problem for group-by queries with limit, instead of paging.
Bug: Test SSTables are in the correct location after range movement with 1/5/20 data directories
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 12/Dec/20 00:34
Resolved: 24/Feb/21 14:12

The testing cluster should be pre-populated with ~200GB data in each node. Change the token ranges and verify that each data directory only contains SSTables belongs to it. In other word, no SSTables are relocated by running nodetool "relocatesstables". Both LCS and STCS need to be covered.
Bug: Python dtests should run at debug
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 02/Oct/20 20:27
Resolved: 10/Nov/20 13:40

At least in our circle configs, we are specifying --log-level="INFO" which often leaves us with nothing to go on when we have a flaky test that only fails in a certain environment.  In general it would be more useful to always run at DEBUG.
Bug: Update jctools dependency
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 09/Nov/20 14:37
Resolved: 20/Nov/20 08:26

CASSANDRA-15880 started using {{MpmcArrayQueue}} from jctools - before that we only used it in cassandra-stress, we should probably update the dependency as jctools-1.2.1 is more than 4 years old
Bug: Flaky NodeToolRingTest
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 20/Nov/20 10:56
Resolved: 20/Nov/20 13:50

NodeToolRingTest is [failing|https://ci-cassandra.apache.org/job/Cassandra-trunk/162/testReport/junit/org.apache.cassandra.distributed.test/NodeToolRingTest/testRingResolve/history/] every now and then. Depending on where it gets executed the host name resolves to localhost or to localhost.localdomain
Bug: Minor Flakiness in ProxyHandlerConnectionsTest#testExpireSomeFromBatch
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 16/Dec/20 19:29
Resolved: 18/Feb/21 23:20

This seems only to be failing in ci-cassandra, but it fails across cdc, compression, and normal configurations there. The only failure recent enough to be retained is here:

https://ci-cassandra.apache.org/job/Cassandra-devbranch/268/testReport/org.apache.cassandra.net/ProxyHandlerConnectionsTest/testExpireSomeFromBatch_compression_2/

{noformat}
org.apache.cassandra.net.ProxyHandlerConnectionsTest.testExpireSomeFromBatch-compression (from org.apache.cassandra.net.ProxyHandlerConnectionsTest-compression)

Error Message

Expired: 8, Arrived: 10

Stacktrace

junit.framework.AssertionFailedError: Expired: 8, Arrived: 10
	at org.apache.cassandra.net.ProxyHandlerConnectionsTest.waitForCondition(ProxyHandlerConnectionsTest.java:285)
	at org.apache.cassandra.net.ProxyHandlerConnectionsTest.lambda$testExpireSomeFromBatch$23(ProxyHandlerConnectionsTest.java:210)
	at org.apache.cassandra.net.ProxyHandlerConnectionsTest.doTestManual(ProxyHandlerConnectionsTest.java:378)
	at org.apache.cassandra.net.ProxyHandlerConnectionsTest.testManual(ProxyHandlerConnectionsTest.java:337)
	at org.apache.cassandra.net.ProxyHandlerConnectionsTest.testExpireSomeFromBatch(ProxyHandlerConnectionsTest.java:169)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)

Standard Output

DEBUG [main] 2020-12-15 20:36:43,018 InternalLoggerFactory.java:45 - Using SLF4J as the default logging framework
DEBUG [main] 2020-12-15 20:36:43,043 PlatformDependent0.java:417 - -Dio.netty.noUnsafe: false
DEBUG [main] 2020-12-15 20:36:43,044 PlatformDependent0.java:897 - Java version: 8
DEBUG [main] 2020-12-15 20:36:43,044 PlatformDependent0.java:130 - sun.misc.Unsafe.theUnsafe: available
DEBUG [main] 2020-12-15 20:36:43,045 PlatformDependent0.java:154 - sun.misc.Unsafe.copyMemory: available

...[truncated 394654 chars]...
ol$Initiate.maybeDecode(HandshakeProtocol.java:167)
	at org.apache.cassandra.net.InboundConnectionInitiator$Handler.initiate(InboundConnectionInitiator.java:242)
	at org.apache.cassandra.net.InboundConnectionInitiator$Handler.decode(InboundConnectionInitiator.java:235)
	at io.netty.handler.codec.ByteToMessageDecoder.decodeRemovalReentryProtection(ByteToMessageDecoder.java:501)
	at io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:440)
	... 29 common frames omitted
{noformat}

There are a number of historical failures listed here, but the runs that produced them have not been retained:

https://ci-cassandra.apache.org/job/Cassandra-trunk/207/testReport/junit/org.apache.cassandra.net/ProxyHandlerConnectionsTest/
Bug: nodetool status owns (effective) question mark
Status: Resolved
Priority: Normal
Resolution: Duplicate
Created: 13/Nov/20 05:57
Resolved: 19/Feb/21 17:56

!image-2020-11-13-13-55-12-609.png!

I'm wondering why the owns (effective) become question mark.. 

I already enabled the 
JVM_OPTS = "$JVM_OPTS -Djava.rmi.server.hostname=public name"
 

Let me know if I missed something..

 

Thanks
Bug: Fix upgrade python dtest test_keys_index_3_x_created - upgrade_tests.thrift_upgrade_test.TestUpgradeTo40
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 10/Dec/20 22:26
Resolved: 08/Jan/21 01:24

https://app.circleci.com/pipelines/github/dcapwell/cassandra/843/workflows/9545f259-0a61-4ba8-8dea-485a33136032/jobs/4964

{code}
test setup failure
file /home/cassandra/cassandra-dtest/upgrade_tests/thrift_upgrade_test.py, line 454
      def test_keys_index_3_x_created(self, from_version):
E       fixture 'from_version' not found
>       available fixtures: cache, capfd, capfdbinary, caplog, capsys, capsysbinary, doctest_namespace, dtest_config, fixture_dtest_cluster_name, fixture_dtest_create_cluster_func, fixture_dtest_setup, fixture_dtest_setup_overrides, fixture_log_test_name_and_date, fixture_logging_setup, fixture_maybe_skip_tests_requiring_novnodes, fixture_ported_to_in_jvm, fixture_since, fixture_skip_version, install_debugging_signal_handler, log_global_env_facts, monkeypatch, pytestconfig, record_property, record_xml_attribute, record_xml_property, recwarn, set_dtest_setup_on_function, tmpdir, tmpdir_factory
>       use 'pytest --fixtures [testpath]' for help on them.

/home/cassandra/cassandra-dtest/upgrade_tests/thrift_upgrade_test.py:454
{code}
Bug: LCS steady state load vs. steady state load with garbagecollect running performance test
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 12/Dec/20 00:30
Resolved: 10/Feb/21 09:24

The testing cluster should be pre-populated with ~200GB data in each node. Run the steady state workload to compare the read, write and compaction performance between before and during garbagecollect is running.
Bug: STCS steady state load vs. steady state load with garbagecollect running performance test
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 12/Dec/20 00:31
Resolved: 10/Feb/21 09:21

The testing cluster should be pre-populated with ~200GB data in each node. Run the steady state workload to compare the read, write and compaction performance between before and during garbagecollect is running.
Bug: LCS steady state load of table with vs. w/o GC performance test
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 12/Dec/20 00:32
Resolved: 10/Feb/21 09:17

The testing cluster should be pre-populated with ~200GB data in each node. The baseline cluster has the table created with {{provide_overlapping_tombstones}} disabled. The other cluster has the table with {{provide_overlapping_tombstones == row}}. Compare the read, write and compaction performance between those 2 clusters.
Bug: STCS steady state load of table with vs. w/o GC performance test
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 12/Dec/20 00:32
Resolved: 10/Feb/21 09:15

The testing cluster should be pre-populated with ~200GB data in each node. The baseline cluster has the table created with {{provide_overlapping_tombstones}} disabled. The other cluster has the table with {{provide_overlapping_tombstones == row}}. Compare the read, write and compaction performance between those 2 clusters.
Bug: STCS steady state load of 4.0 vs 3.x performance test. 
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 12/Dec/20 00:33
Resolved: 10/Feb/21 09:09

The testing cluster should be pre-populated with ~200GB data in each node. Run the steady state workload to compare the read, write and compaction performance between baseline (3.x cluster) and 4.0 cluster.
Bug: LCS steady state load of 4.0 vs. 3.x performance test
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 12/Dec/20 00:33
Resolved: 10/Feb/21 09:04

The testing cluster should be pre-populated with ~200GB data in each node. Run the steady state workload to compare the read, write and compaction performance between baseline (3.x cluster) and 4.0 cluster.
Bug: Reduce amount of allocations during batch statement execution
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 08/Oct/20 13:34
Resolved: 22/Jan/21 10:03

In a Cas 2.1 / 3.0 / 3.11 / 4.0b2 comparison test with the same load profile, we see 4.0b2 going OOM from time to time. According to a heap dump, we have multiple NTR threads in a 3-digit MB range.

This is likely related to object array pre-allocations at the size of {{BatchUpdatesCollector.updatedRows}} per {{BTree}} although there is always only 1 {{BTreeRow}} in the {{BTree}}.
 !screenshot-1.png|width=100%! 

So it seems we have many, many 20K elemnts pre-allocated object arrays resulting in a shallow heap of 80K each, although there is only one element in the array.

This sort of pre-allocation is causing a lot of memory pressure.
Bug: LongSharedExecutorPoolTest.testPromptnessOfExecution burn test is flaky
Status: Resolved
Priority: Normal
Resolution: Duplicate
Created: 06/Nov/20 13:39
Resolved: 20/Jan/21 16:04

Within the burn tests {{LongSharedExecutorPoolTest.testPromptnessOfExecution}} fail regularily with the following stacktrace:

{code}
junit.framework.AssertionFailedError
	at org.apache.cassandra.concurrent.LongSharedExecutorPoolTest.testPromptnessOfExecution(LongSharedExecutorPoolTest.java:213)
	at org.apache.cassandra.concurrent.LongSharedExecutorPoolTest.testPromptnessOfExecution(LongSharedExecutorPoolTest.java:102)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
{code}
Bug: Fix client push notifications in protocol v5
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 15/Dec/20 18:00
Resolved: 19/Jan/21 14:37

The changes to native protocol v5 in CASSANDRA-15299 broke the delivery of push notifications from server to client. This wasn't caught earlier as there weren't any unit or dtests which would exercise client notifications in a beta protocol version. Working on CASSANDRA-14973 to bring v5 out of beta exposed the regression.
Bug: Cassandra fails to start after schema changed
Status: Triage Needed
Priority: Normal
Created: 09/Dec/20 14:26

I'm using Cassandra 3.11.6 on Centos 7 with a 3 node cluster, I ran some schema changes, drop tables/materialized views, alter tables, etc, after that one of the materialized views was failing with this error: 
 org.apache.cassandra.schema.SchemaKeyspace$MissingColumns: No partition key columns found in schema table for my_keyspace.my_materialized_view.

 

I wanted to replace that materialized view with a table, with the same name though, that might be why it's failing

 

I ran nodetool describecluster and found the schema version was different, I tried to run a repair, it didn't work, I restarted the nodes, but they didn't start.

This is the error that is showing up in cassandra.log

 
{code}
ERROR [main] 2020-12-09 10:13:15,827 SchemaKeyspace.java:1017 - No partition columns found for table my_keyspace.my_materialized_view in system_schema.columns. This may be due to corruption or concurrent dropping and altering of a table. If this table is supposed to be dropped, run the following query to cleanup: "DELETE FROM system_schema.tables WHERE keyspace_name = 'my_keyspace' AND table_name = 'my_materialized_view'; DELETE FROM system_schema.columns WHERE keyspace_name = 'my_keyspace' AND table_name = 'my_materialized_view';" If the table is not supposed to be dropped, restore system_schema.columns sstables from backups.
 org.apache.cassandra.schema.SchemaKeyspace$MissingColumns: No partition key columns found in schema table for my_keyspace.my_materialized_view
 at org.apache.cassandra.schema.SchemaKeyspace.fetchColumns(SchemaKeyspace.java:1106) [apache-cassandra-3.11.6.jar:3.11.6]
 at org.apache.cassandra.schema.SchemaKeyspace.fetchTable(SchemaKeyspace.java:1046) [apache-cassandra-3.11.6.jar:3.11.6]
 at org.apache.cassandra.schema.SchemaKeyspace.fetchTables(SchemaKeyspace.java:1000) [apache-cassandra-3.11.6.jar:3.11.6]
 at org.apache.cassandra.schema.SchemaKeyspace.fetchKeyspace(SchemaKeyspace.java:959) [apache-cassandra-3.11.6.jar:3.11.6]
 at org.apache.cassandra.schema.SchemaKeyspace.fetchKeyspacesWithout(SchemaKeyspace.java:936) [apache-cassandra-3.11.6.jar:3.11.6]
 at org.apache.cassandra.schema.SchemaKeyspace.fetchNonSystemKeyspaces(SchemaKeyspace.java:924) [apache-cassandra-3.11.6.jar:3.11.6]
 at org.apache.cassandra.config.Schema.loadFromDisk(Schema.java:92) [apache-cassandra-3.11.6.jar:3.11.6]
 at org.apache.cassandra.config.Schema.loadFromDisk(Schema.java:82) [apache-cassandra-3.11.6.jar:3.11.6]
 at org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:269) [apache-cassandra-3.11.6.jar:3.11.6]
 at org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:630) [apache-cassandra-3.11.6.jar:3.11.6]
 at org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:757) [apache-cassandra-3.11.6.jar:3.11.6]
{code}
 

I tried starting Cassandra with -Dcassandra.ignore_corrupted_schema_tables=true and it doesn't work.

 

Is there a way to fix this?
Bug: Incorrect check for -Xlog in cassandra-env.sh 
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 17/Nov/20 12:59
Resolved: 08/Jan/21 21:08

Possible small bug in {{cassandra-env.sh}} of Cassandra 4:
 [https://github.com/apache/cassandra/blob/trunk/conf/cassandra-env.sh#L98]
 The following command incorrect:
 {code}
 echo "$JVM_OPTS" | grep -q "^-[X]log:gc"
{code}

 Should be:
{code}
echo "$JVM_OPTS" | grep -qe "-[X]log:gc"
{code}
 The variable  {{$JVM_OPTS}} not starting with {{-Xlog..}}  , and always return 1, remove {{^}} and add {{-qe}}  will solve the problem.
 It's causing that {{cassandra-env.sh}}  ignoring variable of {{-Xlog}}  in {{jvm11-server.options}} and {{jvm8-server.options}}

 

Right now, jvm11-server.options with:
{code:java}
-Xlog:gc=info,heap*=trace,age*=debug,safepoint=info,promotion*=trace:file=/var/log/cassandra/gc.log:time,uptime,pid,tid,level:filecount=10,filesize=100M{code}
Will generate process of:
{code:java}
-Xlog:gc=info,heap*=trace,age*=debug,safepoint=info,promotion*=trace:file=/var/log/cassandra/gc.log:time,uptime,pid,tid,level:filecount=10,filesize=100M -Xlog:gc=info,heap*=trace,age*=debug,safepoint=info,promotion*=trace:file=/var/log/cassandra/gc.log:time,uptime,pid,tid,level:filecount=10,filesize=10485760
{code}

With fix it will generate correct gc option of :
{code}
-Xlog:gc=info,heap*=trace,age*=debug,safepoint=info,promotion*=trace:file=/var/log/cassandra/gc.log:time,uptime,pid,tid,level:filecount=10,filesize=100M
{code}
Bug: Fix failing upgrade dtest test_basic_paging - upgrade_tests.paging_test.TestPagingDataNodes
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 10/Dec/20 22:22
Resolved: 08/Jan/21 18:17

test_basic_paging - upgrade_tests.paging_test.TestPagingDataNodes
upgrade_tests/paging_test.py

https://app.circleci.com/pipelines/github/dcapwell/cassandra/843/workflows/9545f259-0a61-4ba8-8dea-485a33136032/jobs/4964

{code}
        #4.0 doesn't support compact storage
>       if version_string == 'trunk' or version_string >= MAJOR_VERSION_4:

upgrade_tests/paging_test.py:476: 
{code}

{code}
self = LooseVersion ('4.0')
other = LooseVersion ('clone:/home/cassandra/cassandra')

    def _cmp (self, other):
        if isinstance(other, str):
            other = LooseVersion(other)
    
        if self.version == other.version:
            return 0
>       if self.version < other.version:
E       TypeError: '<' not supported between instances of 'int' and 'str'
{code}
Bug: Fix upgrade python dtest upgrade_tests/upgrade_through_versions_test.py
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 12/Dec/20 21:12
Resolved: 08/Jan/21 17:52

https://app.circleci.com/pipelines/github/dcapwell/cassandra/846/workflows/bee81d86-f720-4fc2-b3e7-7ed19ec3c9f0/jobs/4988/tests

upgrade_tests/upgrade_through_versions_test.py seems to have a set of tests which fail with the following

{code}
>           raise RuntimeError(message)
E           RuntimeError: A subprocess has terminated early. Subprocess statuses: Process-1 (is_alive: True), Process-2 (is_alive: False), attempting to terminate remaining subprocesses now.

upgrade_tests/upgrade_through_versions_test.py:418: RuntimeError
{code}

The tests found to be failing were:
test_rolling_upgrade_with_internode_ssl
test_rolling_upgrade
Bug: python dtest fails to talk to 2.2 using protocol 4 but cqlsh has no issue
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 15/Dec/20 20:03
Resolved: 08/Jan/21 17:45

https://app.circleci.com/pipelines/github/dcapwell/cassandra/850/workflows/79486fdd-06d0-4d04-aa32-0fa648182356/jobs/5019/artifacts

We see that upgrade tests which talk to 2.2 clusters fail with the following error

{code}
>   ???
E   cassandra.cluster.NoHostAvailable: ('Unable to connect to any servers', {'127.0.0.1:9042': DriverException('ProtocolError returned from server while using explicitly set client protocol_version 4',)})
{code}

For some reason, setting protocol version 4 causes 2.2 to fail, but this does not happen when using cqlsh (from trunk) 

{code}
./bin/cqlsh --protocol-version=4
Connected to Test Cluster at 127.0.0.1:9042.
[cqlsh 5.0.1 | Cassandra 2.2.20-SNAPSHOT | CQL spec 3.3.1 | Native protocol v4]
Use HELP for help.
{code}
Bug: Fix upgrade python dtest test_static_columns_with_2i - upgrade_tests.cql_tests.TestCQLNodes
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 10/Dec/20 22:30
Resolved: 19/Dec/20 00:51

https://app.circleci.com/pipelines/github/dcapwell/cassandra/843/workflows/9545f259-0a61-4ba8-8dea-485a33136032/jobs/4964

{code}
            # We don't support that
>           assert_invalid(cursor, "SELECT s FROM test WHERE v = 1")

upgrade_tests/cql_tests.py:4137: 
{code}

{code}
>           assert False, "Expecting query to raise an exception, but nothing was raised."
E           AssertionError: Expecting query to raise an exception, but nothing was raised.

tools/assertions.py:63: AssertionError
{code}
Bug: Update python driver used by cassandra-dtest
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 13/Nov/20 17:35
Resolved: 01/Dec/20 19:01

In order to commit CASSANDRA-15299, the python driver used by the dtests needs to include PYTHON-1258, support for V5 framing. 

Updating the python driver's cassandra-test branch to latest trunk causes 1 additional dtest failure in {{auth_test.py::TestAuth::test_handle_corrupt_role_data}} because the {{ServerError}} response is now subject to the configured {{retry_policy}}. This means the error ultimately returned from the driver is {{NoHostAvailable}}, rather than {{ServerError}}. 

I'll open a dtest pr to change the expectation in the test and we can commit that when the cassandra-test branch is updated.

cc [~aholmber] [~aboudreault]