av9ash/GitBugs huggingface dataset:
Bug: Flaky Test - 	LongLeveledCompactionStrategyCQLTest
Status: Open
Priority: Normal
Created: 14/Feb/22 18:55

The test fails on 3.11 with such an issue:

{code}

ERROR [CompactionExecutor:2] 2022-02-07 13:29:52,856 CQLTester.java:184 - Fatal exception in thread Thread[CompactionExecutor:2,1,main] java.lang.AssertionError: Got unexpected overlap in level 2 at org.apache.cassandra.db.compaction.LeveledGenerations.addAll(LeveledGenerations.java:159) at org.apache.cassandra.db.compaction.LeveledManifest.addSSTables(LeveledManifest.java:132) at org.apache.cassandra.db.compaction.LeveledCompactionStrategy.addSSTable(LeveledCompactionStrategy.java:351) at org.apache.cassandra.db.compaction.CompactionStrategyManager.startup(CompactionStrategyManager.java:216) at org.apache.cassandra.db.compaction.CompactionStrategyManager.reload(CompactionStrategyManager.java:393) at org.apache.cassandra.db.compaction.CompactionStrategyManager.maybeReloadDiskBoundaries(CompactionStrategyManager.java:356) at org.apache.cassandra.db.compaction.CompactionStrategyManager.handleNotification(CompactionStrategyManager.java:579) at org.apache.cassandra.db.lifecycle.Tracker.notifySSTablesChanged(Tracker.java:429) at org.apache.cassandra.db.lifecycle.LifecycleTransaction.doCommit(LifecycleTransaction.java:234) at org.apache.cassandra.utils.concurrent.Transactional$AbstractTransactional.commit(Transactional.java:113) at org.apache.cassandra.io.sstable.SSTableRewriter.doCommit(SSTableRewriter.java:207)

{code}

[https://ci-cassandra.apache.org/job/Cassandra-3.11/316/testReport/org.apache.cassandra.db.compaction/LongLeveledCompactionStrategyCQLTest/stressTestCompactionStrategyManager/]

[https://ci-cassandra.apache.org/job/Cassandra-3.11/318/testReport/org.apache.cassandra.db.compaction/LongLeveledCompactionStrategyCQLTest/stressTestCompactionStrategyManager/]
Bug: Test Failure: dtest-upgrade.upgrade_tests.upgrade_through_versions_test.TestUpgrade_current_3_0_x_To_indev_3_0_x.test_rolling_upgrade (from Cassandra dtests)
Status: Open
Priority: Normal
Created: 27/Jan/22 17:52

Failed 16 times in the last 16 runs. Flakiness: 0%, Stability: 0%
h3. Error Message

RuntimeError: A subprocess has terminated early. Subprocess statuses: Process-1 (is_alive: True), Process-2 (is_alive: False), attempting to terminate remaining subprocesses now.

 {code}
Stacktrace
self = <upgrade_tests.upgrade_through_versions_test.TestUpgrade_current_3_0_x_To_indev_3_0_x object at 0x7fac42587190>

    @pytest.mark.timeout(3000)
    def test_rolling_upgrade(self):
        """
            Test rolling upgrade of the cluster, so we have mixed versions part way through.
            """
>       self.upgrade_scenario(rolling=True)

upgrade_tests/upgrade_through_versions_test.py:320: 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
upgrade_tests/upgrade_through_versions_test.py:398: in upgrade_scenario
    self._check_on_subprocs(self.fixture_dtest_setup.subprocs)
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 

self = <upgrade_tests.upgrade_through_versions_test.TestUpgrade_current_3_0_x_To_indev_3_0_x object at 0x7fac42587190>
subprocs = [<Process name='Process-1' pid=30475 parent=320 stopped exitcode=-SIGKILL daemon>, <Process name='Process-2' pid=30494 parent=320 stopped exitcode=1 daemon>]

    def _check_on_subprocs(self, subprocs):
        """
            Check on given subprocesses.
    
            If any are not alive, we'll go ahead and terminate any remaining alive subprocesses since this test is going to fail.
            """
        subproc_statuses = [s.is_alive() for s in subprocs]
        if not all(subproc_statuses):
            message = "A subprocess has terminated early. Subprocess statuses: "
            for s in subprocs:
                message += "{name} (is_alive: {aliveness}), ".format(name=s.name, aliveness=s.is_alive())
            message += "attempting to terminate remaining subprocesses now."
            self._terminate_subprocs()
>           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:456: RuntimeError
{code}
Bug: Test Failure: dtest-novnode.repair_tests.repair_test.TestRepair.test_simple_repair_order_preserving (from Cassandra dtests)
Status: Open
Priority: Normal
Created: 27/Jan/22 18:00

https://ci-cassandra.apache.org/job/Cassandra-3.0/240/testReport/dtest-novnode.repair_tests.repair_test/TestRepair/test_simple_repair_order_preserving/

Failed 2 times in the last 27 runs. Flakiness: 11%, Stability: 92%
Error Message
cassandra.DriverException: ID mismatch while trying to reprepare (expected b'ba2c66a4f13080265ea718e037637d4a', got b'52faf62235132756a26828817a81168d'). This prepared statement won't work anymore. This usually happens when you run a 'USE...' query after the statement was prepared.

{code}
Stacktrace
self = <repair_tests.repair_test.TestRepair object at 0x7f4d10c146d0>

    @pytest.mark.no_vnodes
    def test_simple_repair_order_preserving(self):
        """
            Calls simple repair test with OPP and sequential repair
            @jira_ticket CASSANDRA-5220
            """
>       self._simple_repair(order_preserving_partitioner=True)

repair_tests/repair_test.py:429: 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
repair_tests/repair_test.py:453: in _simple_repair
    self._populate_cluster()
repair_tests/repair_test.py:117: in _populate_cluster
    insert_c1c2(session, keys=list(range(1001, 2001)), consistency=ConsistencyLevel.ALL, ks='ks')
tools/data.py:36: in insert_c1c2
    execute_concurrent_with_args(session, statement, [['k{}'.format(k)] for k in keys])
../venv/src/cassandra-driver/cassandra/concurrent.py:238: in execute_concurrent_with_args
    return execute_concurrent(session, zip(cycle((statement,)), parameters), *args, **kwargs)
../venv/src/cassandra-driver/cassandra/concurrent.py:94: in execute_concurrent
    return executor.execute(concurrency, raise_on_first_error)
../venv/src/cassandra-driver/cassandra/concurrent.py:201: in execute
    return super(ConcurrentExecutorListResults, self).execute(concurrency, fail_fast)
../venv/src/cassandra-driver/cassandra/concurrent.py:120: in execute
    return self._results()
../venv/src/cassandra-driver/cassandra/concurrent.py:219: in _results
    self._raise(self._exception)
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 

exc = DriverException("ID mismatch while trying to reprepare (expected b'ba2c66a4f13080265ea718e037637d4a', got b'52faf62235...ed statement won't work anymore. This usually happens when you run a 'USE...' query after the statement was prepared.")

    @staticmethod
    def _raise(exc):
        if six.PY2 and isinstance(exc, tuple):
            (exc_type, value, traceback) = exc
            six.reraise(exc_type, value, traceback)
        else:
>           raise exc
E           cassandra.DriverException: ID mismatch while trying to reprepare (expected b'ba2c66a4f13080265ea718e037637d4a', got b'52faf62235132756a26828817a81168d'). This prepared statement won't work anymore. This usually happens when you run a 'USE...' query after the statement was prepared.

../venv/src/cassandra-driver/cassandra/concurrent.py:167: DriverException
{code}
Bug: Test Failure: junit.framework.TestSuite.org.apache.cassandra.distributed.test.PreviewRepairCoordinatorFastTest 
Status: Open
Priority: Normal
Created: 26/Jan/22 17:39

https://ci-cassandra.apache.org/job/Cassandra-4.0/321/testReport/junit.framework/TestSuite/org_apache_cassandra_distributed_test_PreviewRepairCoordinatorFastTest/

Failed 1 times in the last 1 runs. Flakiness: 0%, Stability: 0%
Error Message
Uncaught exceptions were thrown during test
{code}
Stacktrace
org.apache.cassandra.distributed.shared.ShutdownException: Uncaught exceptions were thrown during test
	at org.apache.cassandra.distributed.impl.AbstractCluster.checkAndResetUncaughtExceptions(AbstractCluster.java:874)
	at org.apache.cassandra.distributed.impl.AbstractCluster.close(AbstractCluster.java:860)
	at org.apache.cassandra.distributed.test.RepairCoordinatorBase.teardownCluster(RepairCoordinatorBase.java:87)
	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)
	Suppressed: java.lang.AssertionError: java.lang.InterruptedException
		at org.apache.cassandra.concurrent.DebuggableThreadPoolExecutor.extractThrowable(DebuggableThreadPoolExecutor.java:308)
		at org.apache.cassandra.concurrent.DebuggableThreadPoolExecutor.extractThrowable(DebuggableThreadPoolExecutor.java:287)
		at org.apache.cassandra.concurrent.DebuggableThreadPoolExecutor.logExceptionsAfterExecute(DebuggableThreadPoolExecutor.java:252)
		at org.apache.cassandra.concurrent.DebuggableThreadPoolExecutor.afterExecute(DebuggableThreadPoolExecutor.java:211)
		at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1131)
		at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
		at io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
		at java.base/java.lang.Thread.run(Thread.java:829)
	Caused by: java.lang.InterruptedException
		at com.google.common.util.concurrent.AbstractFuture.get(AbstractFuture.java:509)
		at org.apache.cassandra.concurrent.DebuggableThreadPoolExecutor.extractThrowable(DebuggableThreadPoolExecutor.java:304)
{code}
Bug: nodetool toppartitions can fail because ByteBuffer.array() returns more bytes than would be considered valid by UTF8Serializer.validate
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 11/Jan/22 00:38
Resolved: 30/Nov/22 02:36

The error below is caused by the use of [{{ByteBuffer.array()}}|https://github.com/apache/cassandra/blob/cassandra-3.0/src/java/org/apache/cassandra/db/ColumnFamilyStore.java#L1628]. Doing so not only makes the hex key potentially incorrect but causes invalid data to be passed to {{AbstractType.getString}} and ultimately {{UTF8Validator.validate}}. 

{code}
error: String didn't validate.
-- StackTrace --
org.apache.cassandra.serializers.MarshalException: String didn't validate.
	at org.apache.cassandra.serializers.UTF8Serializer.validate(UTF8Serializer.java:35)
	at org.apache.cassandra.db.marshal.AbstractType.getString(AbstractType.java:129)
	at org.apache.cassandra.db.ColumnFamilyStore.finishLocalSampling(ColumnFamilyStore.java:1633)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
{code}
Bug: Use only one image for all CircleCI builds; Switch to "latest" tag
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 10/Mar/22 17:40
Resolved: 09/Jun/23 20:59

While working on the latest CircleCI issues, we noticed some inconsistencies in our config.

There were different images used in CircleCI for Java 8 and Java 11. 

We need to use only the latest images everywhere, same as in Jenkins.

Also, we use specific date tag which is inconvenient as every time a new image is published, we need to change the tag in config.yml on all Cassandra branches. Better to switch to "latest" tag as we already use it successfully in Jenkins.
Bug: Add hooks for the Javascript UDF to enable people to plugin their own implementations of scripted UDFs
Status: Open
Priority: Normal
Created: 23/Jan/22 17:44

[Consensus |https://lists.apache.org/thread/mnxh94lg9v94bfntq88051z3ww16q2fk]  was reached to remove JavaScript UDF with the next major release. 

We need to leave an interface for those who would like to supply a UDF implementation.
Bug: Move cassandra.yaml toward a nested structure around major database concepts
Status: Open
Priority: Normal
Created: 25/Jan/22 17:43

Recent mailing list conversation (see "[DISCUSS] Nested YAML configs for new features") has made it clear we will gravitate toward appropriately nested structures for new parameters in {{cassandra.yaml}}, but from the scattered conversation across a few Guardrails tickets (see CASSANDRA-17212 and CASSANDRA-17148) and CASSANDRA-15234, there is also a general desire to eventually extend this to the rest of {{cassandra.yaml}}. The benefits of this change include those we gain by doing it for new features (single point of interest for feature documentation, typed configuration objects, logical grouping for additional parameters added over time, discoverability, etc.), but on a larger scale.

This may overlap with ongoing work, including the Guardrails epic. Ideally, even a rough cut of a design here would allow that to move forward in a timely and coherent manner (with less long-term refactoring pain).

Current proposals:

From [~benedict] - https://github.com/belliottsmith/cassandra/commits/CASSANDRA-15234-grouping-ideas

From [~maedhroz] - https://github.com/maedhroz/cassandra/commit/450b920e0ac072cec635e0ebcb63538ee7f1fc5a

From [~paulo] - https://gist.github.com/pauloricardomg/e9e23feea1b172b4f084cb01d7a89b05 & https://gist.github.com/pauloricardomg/4369f4b0dd8b84421a11ae61bf2d2c7e
Bug: USING writetime + ttl is non-idempotent leading to non-deterministic merge iteration results
Status: Patch Available
Priority: Normal
Created: 11/Jan/22 00:00

The combination of {{USING writetime = timestamp and ttl = ttl}} can result in non-deterministic MergeIterator results causing DigestMismatchExceptions and increased latencies. The increased latencies are caused by additional round trips due to the digest mismatch as well as read repair rewriting the data. The additional writes lead to an increase in the number of sstables the key is stored in and must be scanned on read.

The order of events is:
1. for a given partition a write is performed with {{USING timestamp = sometime and ttl = ttl1}}.
2. Cassandra records this write with timestamp = sometime, ttl = ttl1, expires_at = now + ttl1
3. after N seconds, for the same partition, another write is performed with {{USING timestamp = sometime and ttl = ttl2 where ttl2 = ttl1 - N}}. This write only makes it to a subset of replicas* for some reason (e.g. partial write, node down, etc).
4. Cassandra records this write with timestamp = sometime, ttl = ttl2, expires_at = now + ttl2. Its important to note that at this point, expires_at in 2 above is equal to expires at here. This is because it is calculated relative to the current write time not the provided timestamp and the ttl has been adjusted by the time passed. This write also makes it to a subset of replicas*.
5. A read of the data is performed.
5a. The MergeIterator resolves conflicts locally (accross sstables) using {{Conflicts.resolveRegular}} or {{Cells.resolveRegular}}. The resolution takes into account the write timestamp , the liveness of the cell, the values themselves, and how much time is left to live via the expires_at field. In this scenario, all of these fields are equal, leading to Cassandra picking the sstable "on the right" – this is non-deterministic. The only item that differs is the ttl itself. 
5b. One node returns the non-deterministically chosen value for the row, the other two calculate and send a digest to the coordinator. The digest includes the relative ttl field which may not match. This results in a DigestMismatchException at the coordinator.
6. Read repair is triggered 

*NOTE: its not strictly necessary for the write to make it to a subset of replicas. sstables can also be ordered in random orders for reasons like compaction or repair when returned from the live set which can lead to the same behavior. This also affects repair from what we can tell.
Bug: Investigate large number of test timeouts on specific build runs
Status: Open
Priority: Normal
Created: 28/Jan/22 18:47

We have a selection of new test failures on CI run 323 on 4.0 and 923 on trunk that appear to have a variety of teardown errors or timeouts. We should look into if there's any kind of theme, commonality, etc that we can make changes w/respect to to prevent this kind of "dud job" from occurring in the future.

323 4.0: https://ci-cassandra.apache.org/job/Cassandra-4.0/323/testReport/
923 trunk: https://ci-cassandra.apache.org/job/Cassandra-trunk/923/

Failures on 4.0:
https://ci-cassandra.apache.org/job/Cassandra-4.0/323/testReport/dtest-novnode.materialized_views_test/TestMaterializedViewsConsistency/test_multi_partition_consistent_reads_after_write/
https://ci-cassandra.apache.org/job/Cassandra-4.0/323/testReport/dtest-novnode.transient_replication_test/TestTransientReplication/test_cheap_quorums/
https://ci-cassandra.apache.org/job/Cassandra-4.0/323/testReport/dtest-novnode.client_request_metrics_test/TestClientRequestMetrics/test_client_request_metrics/
https://ci-cassandra.apache.org/job/Cassandra-4.0/323/testReport/dtest-novnode.repair_tests.repair_test/TestRepair/test_multiple_ranges_repair/
https://ci-cassandra.apache.org/job/Cassandra-4.0/323/testReport/org.apache.cassandra.net/ProxyHandlerConnectionsTest/testExpireSome/

Notably, trunk build 923 appears to have the same pattern of a slew of untraced timeouts on tests:
https://ci-cassandra.apache.org/job/Cassandra-trunk/923/testReport/org.apache.cassandra.distributed.upgrade/CompactStorageUpgradeTest/compactStorageHiddenColumnTest/
https://ci-cassandra.apache.org/job/Cassandra-trunk/923/testReport/org.apache.cassandra.transport/CQLConnectionTest/handleCorruptionOfLargeMessageFrame_compression_2/
https://ci-cassandra.apache.org/job/Cassandra-trunk/923/testReport/org.apache.cassandra.distributed.test/NetstatsRepairStreamingTest/testWithCompressionEnabled/
https://ci-cassandra.apache.org/job/Cassandra-trunk/923/testReport/org.apache.cassandra.distributed.test/NetstatsBootstrapWithEntireSSTablesCompressionStreamingTest/testWithStreamingEntireSSTablesWithoutCompressionWithoutThrottling_4/
https://ci-cassandra.apache.org/job/Cassandra-trunk/923/testReport/org.apache.cassandra.net/ProxyHandlerConnectionsTest/testExpireSome_compression/
https://ci-cassandra.apache.org/job/Cassandra-trunk/923/testReport/dtest-novnode.transient_replication_test/TestTransientReplication/test_transient_write/
https://ci-cassandra.apache.org/job/Cassandra-trunk/923/testReport/dtest-novnode.read_repair_test/TestSpeculativeReadRepair/test_quorum_requirement_on_speculated_read/
Bug: Security admin separation of duties
Status: Patch Available
Priority: Normal
Created: 30/Mar/22 07:02

This ticket is about enabling a sort of security admin role.

Think of a hospital with patient data which is very sensitive information. IT should be able to grant/revoke/restrict access to the data without having access to the data itself. This is the clear separation of duties between admins and users of the database we're after.

An example is along the lines:

{noformat}

As a superuser:
CREATE KEYSPACE patientdata …;
CREATE ROLE security_admin;
GRANT security_admin TO admin_guy;
GRANT AUTHORIZE FOR SELECT, MODIFY, EXECUTE ON patientdata TO security_admin;
RESTRICT SELECT, MODIFY, EXECUTE ON KEYSPACE patientdata TO security_admin;

As a security admin:
GRANT SELECT ON patientdata TO new_nurse;
GRANT SELECT, MODIFY ON patientdata TO doctor_house;
{noformat}


 Original idea of [~snazy]
Bug: Merge guardrails and track warnings configurations
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 02/Feb/22 15:56
Resolved: 22/Mar/23 19:14

As discussed in CASSANDRA-17148, a first step for the integration between guardrails and track warnings is merging their configurations, which are almost identical. This ticket would cover merging their config sections in {{cassandra.yaml}} and their corresponding JMX getters and setters. A tighter integration between the internals of both features wouldn't be part of this ticket, but of either CASSANDRA-17148 or a new subtask of it.

Neither guardrails nor track warnings have included in any release, so it would be desirable to do this before releasing 4.1 so we don't have to deprecate properties.

There's an ongoing discussion about refactoring {{cassandra.yaml}} spread across CASSANDRA-17292, CASSANDRA-17188 and CASSANDRA-17212. I understand that any change affecting the config for guardrails also affects the config track warnings, because they are almost identical. Thus, I think that merging both config sections would ease any refactoring plan that is agreed on that discussion.
Bug: Fix   org.apache.cassandra.db.commitlog.CommitLogSegmentManagerCDCTest.testNonblockingShouldMaintainSteadyDiskUsage
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 03/Jan/22 22:00
Resolved: 17/Feb/22 06:57

Fails consistently on trunk:

https://ci-cassandra.apache.org/job/Cassandra-trunk/893/testReport/junit/org.apache.cassandra.db.commitlog/CommitLogSegmentManagerCDCTest/testNonblockingShouldMaintainSteadyDiskUsage/history/
Bug: flaky in jvm CasCriticalSectionTest.criticalSectionTest
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 18/Mar/22 10:47
Resolved: 28/Apr/22 07:47

From CI, there are variations of this error:
{code:java}
org.apache.cassandra.exceptions.CasWriteTimeoutException: CAS operation timed out: received 0 of 3 required responses after 0 contention retries at org.apache.cassandra.service.paxos.Paxos$MaybeFailure.markAndThrowAsTimeoutOrFailure(Paxos.java:547) at org.apache.cassandra.service.paxos.Paxos.cas(Paxos.java:732) at org.apache.cassandra.service.paxos.Paxos.cas(Paxos.java:618) at org.apache.cassandra.service.StorageProxy.cas(StorageProxy.java:307) at org.apache.cassandra.cql3.statements.ModificationStatement.executeWithCondition(ModificationStatement.java:500) at org.apache.cassandra.cql3.statements.ModificationStatement.execute(ModificationStatement.java:467) at org.apache.cassandra.distributed.impl.Coordinator.unsafeExecuteInternal(Coordinator.java:122) at org.apache.cassandra.distributed.impl.Coordinator.unsafeExecuteInternal(Coordinator.java:103) at org.apache.cassandra.distributed.impl.Coordinator.lambda$executeWithResult$0(Coordinator.java:66) at org.apache.cassandra.concurrent.FutureTask.call(FutureTask.java:47) at org.apache.cassandra.concurrent.FutureTask.run(FutureTask.java:57) at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) at io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30) at java.base/java.lang.Thread.run(Thread.java:829) {code}
Bug: Instance failed to start up due to NPE in StartupClusterConnectivityChecker
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 04/Feb/22 00:58
Resolved: 09/Feb/22 18:25

Instance is crashing during startup due to a NPE in StartupClusterConnectivityChecker with stack trace:
{noformat}
java.lang.NullPointerException: element cannot be mapped to a null key
        at java.util.Objects.requireNonNull(Objects.java:228)
        at java.util.stream.Collectors.lambda$groupingBy$45(Collectors.java:907)
        at java.util.stream.ReduceOps$3ReducingSink.accept(ReduceOps.java:169)
        at java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1382)
        at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:482)
        at java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:472)
        at java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:708)
        at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
        at java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:566)
        at org.apache.cassandra.net.StartupClusterConnectivityChecker.execute(StartupClusterConnectivityChecker.java:173)
{noformat}