av9ash/GitBugs huggingface dataset:
Bug: Fix org.apache.cassandra.distributed.test.UnableToParseClientMessageTest.badHeader[version=5/v5]
Status: Resolved
Priority: Normal
Resolution: Cannot Reproduce
Created: 17/Sep/21 21:54
Resolved: 01/Jun/22 14:44

org.apache.cassandra.distributed.test.UnableToParseClientMessageTest.badHeader[version=5/v5  is [failing|https://jenkins-cm4.apache.org/job/Cassandra-devbranch/1121/testReport/junit/org.apache.cassandra.distributed.test/UnableToParseClientMessageTest/badHeader_version_5_v5_/] on trunk


{code:java}
Error Message
Expecting actual not to be empty
Stacktrace
junit.framework.AssertionFailedError: 
Expecting actual not to be empty
	at org.apache.cassandra.distributed.test.UnableToParseClientMessageTest.test(UnableToParseClientMessageTest.java:158)
	at org.apache.cassandra.distributed.test.UnableToParseClientMessageTest.badHeader(UnableToParseClientMessageTest.java:99)
	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: WEBSITE - Case studies hyperlink for Coursera leads to a 404 page
Status: Open
Priority: Normal
Created: 18/Aug/21 13:38

At [https://cassandra.apache.org/_/case-studies.html] when I click on {{READ MORE}} button/link for Coursera, it is taking me to [https://www.datastax.com/enterprise-success/coursera] which ends up being a 404 page. Please address the same.
Bug: jvm-dtest-upgrade failing MixedModeReadTest.mixedModeReadColumnSubsetDigestCheck: Error while transfering object to InstanceClassLoader
Status: Open
Priority: Normal
Created: 27/Sep/21 16:40

As seen [here|https://jenkins-cm4.apache.org/job/Cassandra-devbranch/1143/testReport/junit/org.apache.cassandra.distributed.upgrade/MixedModeReadTest/mixedModeReadColumnSubsetDigestCheck/] it looks like CASSANDRA-16803 wasn't a complete solution.
Bug: Remove ssl_storage_port and server_encryption_options.enable_legacy_ssl_storage_port
Status: Open
Priority: Normal
Created: 07/Aug/21 09:06

{{ssl_storage_port}} was deprecated in 4.0a-alpha1

It can still be used if {{server_encryption_options.enable_legacy_ssl_storage_port}} is true.

In 4.1 both properties can be removed.
Bug: Abort repairs whose streaming jobs will push disk usage over a configurable threshold
Status: Open
Priority: Normal
Created: 13/Jul/21 19:17

When nodes are out of sync, it is possible to get into a situation where streaming from repairs sends us to 100% disk usage (from a starting point of 20% even, in matter of hours). Since we know the size of the data we're going to stream over, and how much disk space is left, we should just fail the streaming instead of causing flush issues on memtables/commitlog/etc. as we approach that point.

Perhaps it would make sense to have a configurable threshold of say 90% disk usage over which we won't accept more streams.
Bug: Race in commit log replay can cause rejected mutations
Status: Review In Progress
Priority: Normal
Created: 24/Aug/21 10:58

We don't force order in the execution of replayed mutations and hence a mutation can move ahead of or behind a schema change it relies on (e.g. added/removed column), which can then cause it to be rejected because of a schema mismatch.

To fix this, we need to identify schema mutations and make sure the log enforces their execution after all previous mutations have completed and before anything following is started.

Schema mutations are [flushed|https://github.com/apache/cassandra/blob/cassandra-4.0.0/src/java/org/apache/cassandra/schema/SchemaKeyspace.java#L1266-L1271] after being applied, so this only would be a problem if the node abruptly stops before flushing the schema mutation.
Bug: Improve the way we pick sstables for STCS-in-L0 and in TWCS 'current' window
Status: Review In Progress
Priority: Normal
Created: 01/Jul/21 14:43

The goal when being behind in L0 should always be to get the number of sstables down to a reasonable level as soon as possible. Currently it is common that we run compactions on the large sstables but leave thousands of tiny sstables behind.
Bug: Task Execution
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 08/Sep/21 17:49
Resolved: 07/Oct/21 11:29

To support CEP-10 it is necessary to support alternative executor implementations that may be externally controlled. This ticket introduces an ExecutorFactory, and all executor creation is migrated to this facility. The codebase’s use of executors is inconsistent, and relatedly there are divergent Future APIs in use, with Netty, Guava and Java APIs in use in various places. To improve consistency we introduce our own Future API that implements all of the above, as well as providing other additional ergonomic improvements. We introduce a new ExecutorPlus API that extends Executor to supply this extended Future API. All executors and futures are ported to these new APIs to improve coherency in the codebase, and to support consistently mocking these implementations.

DebuggableThreadPoolExecutor and its hierarchy is replaced with ThreadPoolExecutorBase, ThreadPoolExecutorPlus and extending classes with consistent names, implementations and configurability.

Additionally the ExecutorFactory takes over the allocation of new threads, and provides a new InfiniteLoopExecutorfacility for common paradigms.
Bug: Java 11 support - remove the experimental flag
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 27/Aug/21 12:53
Resolved: 24/Jan/22 17:56

As per this [thread. |https://lists.apache.org/thread.html/r06a4768bae215dc19469491a1faec64dd90e1c3d4d10ed34b85ba248%40%3Cdev.cassandra.apache.org%3E]the goal of this ticket is to remove the experimental flag for Java 11 support.
Bug: Add upgrade path to documentation
Status: Open
Priority: Normal
Created: 21/Jul/21 17:17

[~berenguerblasi@gmail.com] says
Upgrade path for 4.0 should be:
 * 2.x -> 3.11
 * 2.x -> 3.0 possible but not recommended
 * [3.0, 3.11] -> 4.0
 
  Also [https://github.com/apache/cassandra-dtest/blob/trunk/upgrade_tests/upgrade_manifest.py]
Bug: Fix ivm-upgrade test org.apache.cassandra.distributed.upgrade.CompactStorageUpgradeTest: compactStorageHiddenColumnTest
Status: Resolved
Priority: Normal
Resolution: Duplicate
Created: 01/Sep/21 00:12
Resolved: 09/Sep/21 17:05

https://app.circleci.com/pipelines/github/dcapwell/cassandra/1017/workflows/3a1caaca-b213-4841-b010-cdcdde73df0b/jobs/6450

This test has been failing for a while
Bug: Fix org.apache.cassandra.distributed.test.ClientTombstoneWarningTest.failThresholdSinglePartition
Status: Resolved
Priority: Normal
Resolution: Not A Problem
Created: 17/Sep/21 21:42
Resolved: 05/Oct/21 15:50

org.apache.cassandra.distributed.test.ClientTombstoneWarningTest.failThresholdSinglePartition is [failing|https://jenkins-cm4.apache.org/job/Cassandra-devbranch/1121/testReport/org.apache.cassandra.distributed.test/ClientTombstoneWarningTest/failThresholdSinglePartition_2/]
{code:java}
Error Message
 expected:<....0.1=1, /127.0.0.2=1[, /127.0.0.3=1]}> but was:<....0.1=1, /127.0.0.2=1[]}>
 Stacktrace
 junit.framework.AssertionFailedError: expected:<....0.1=1, /127.0.0.2=1[, /127.0.0.3=1]}> but was:<....0.1=1, /127.0.0.2=1[]}>
 at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
 at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
 at java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
 at org.apache.cassandra.distributed.test.ClientTombstoneWarningTest.failThreshold(ClientTombstoneWarningTest.java:227)
 at org.apache.cassandra.distributed.test.ClientTombstoneWarningTest.failThresholdSinglePartition(ClientTombstoneWarningTest.java:180)
 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: Update jbcrypt library to 0.4 from 0.3m to resolve CVE-2015-0886
Status: Resolved
Priority: Normal
Resolution: Duplicate
Created: 24/Sep/21 09:40
Resolved: 24/Sep/21 11:46

We are using jbcrypto of version 0.3m across all versions, this version of the library was never changed since 1.1.2.

In 0.3m they found out this (1) and (2, 3 for better explanation / reference)

I think we are affected by this, it is possible to set 31 rounds here (4) which would hit the same same logic afteward these tickets are talking about.

1) [https://nvd.nist.gov/vuln/detail/CVE-2015-0886]

2) [http://www.mindrot.org/projects/jBCrypt/news/rel04.html]

3) [https://bugzilla.mindrot.org/show_bug.cgi?id=2097]

4) [https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/auth/CassandraRoleManager.java#L105-L117]

I  hence propose to update the library to 0.4 where this is fixed.
Bug: Dockerise cqlshlib tests
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 17/Jul/21 21:05
Resolved: 09/Aug/21 20:20

The cqlshlib tests are the last remaining tests that don't run in docker.

Before 4.0 the cqlshlib builds are [hardcoded|https://github.com/apache/cassandra/blob/cassandra-3.11/pylib/cassandra-cqlsh-tests.sh#L60] to python2, but the test docker image [doesn't support python2|https://github.com/apache/cassandra-builds/blob/trunk/docker/testing/ubuntu2004_j11.docker#L99-L117].

(Maybe this is why cqlshlib tests don't exist in pre 4.0 circleci?)

Dockerising the cqlshlib tests, makes it a lot easier to keep jenkins' agents clean of zombie processes. 

Patches: 
- cassandra-builds: https://github.com/apache/cassandra-builds/pull/50
- 3.11: https://github.com/apache/cassandra/compare/cassandra-3.11...thelastpickle:mck/dockerise-cqlsh-tests/3.11
- 3.0: https://github.com/apache/cassandra/compare/cassandra-3.0...thelastpickle:mck/dockerise-cqlsh-tests/3.0

Patches are not required for 4.0 and trunk, as the {{--no-site-packages}} flag to virtualenv has already been removed from them.
Bug: CEP-10: Simulator
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 28/Sep/21 14:38
Resolved: 30/Nov/21 16:08

This ticket introduces the Simulator facility proposed by CEP-10, including mock implementations of: time, blocking concurrency primitives, executors, messaging, object monitors, identity hashcode, and byte weaving class loaders to ensure these mock implementations are utilised in place of their originals.
Bug: System Clock
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 08/Sep/21 17:48
Resolved: 29/Sep/21 22:57

To support CEP-10 and other project testing goals, it is necessary to support supplying a non-standard time source that can be externally controlled. This ticket modifies existing abstractions and migrates all calls to System.currentTimeMillis() and System.nanoTime() to these APIs.
Bug: Fix flaky test consistent_bootstrap_test.py::TestBootstrapConsistency::test_consistent_reads_after_move
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 03/Aug/21 20:23
Resolved: 24/May/22 14:52

consistent_bootstrap_test.py::TestBootstrapConsistency::test_consistent_reads_after_move can be flaky from time to time on less powerful environments due to timeouts; this can be improved by having retries for queries

Here is the error I was seeing

{code}
self =  <consistent_bootstrap_test.TestBootstrapConsistency object at 0x7fad988790f0>
     @pytest.mark.no_vnodes
    def test_consistent_reads_after_move(self):
        logger.debug("Creating a ring")
        cluster = self.cluster
        cluster.set_configuration_options(values={'hinted_handoff_enabled': False,
                                                  'write_request_timeout_in_ms': 60000,
                                                  'read_request_timeout_in_ms': 60000,
                                                  'dynamic_snitch_badness_threshold': 0.0})
        cluster.set_batch_commitlog(enabled=True)
   
        cluster.populate(3, tokens=[0, 2**48, 2**62]).start()
        node1, node2, node3 = cluster.nodelist()
   
        logger.debug("Set to talk to node 2")
        n2session = self.patient_cql_connection(node2)
        create_ks(n2session, 'ks', 2)
        create_c1c2_table(self, n2session)
   
        logger.debug("Generating some data for all nodes")
        insert_c1c2(n2session, keys=list(range(10, 20)), consistency=ConsistencyLevel.ALL)
   
        node1.flush()
        logger.debug("Taking down node1")
        node1.stop(wait_other_notice=True)
   
        logger.debug("Writing data to node2")
        insert_c1c2(n2session, keys=list(range(30, 1000)), consistency=ConsistencyLevel.ONE)
        node2.flush()
   
        logger.debug("Restart node1")
        node1.start()
   
        logger.debug("Move token on node3")
        node3.move(2)
   
        logger.debug("Checking that no data was lost")
        for n in range(10, 20):
            query_c1c2(n2session, n, ConsistencyLevel.ALL)
   
        for n in range(30, 1000):
>            query_c1c2(n2session, n, ConsistencyLevel.ALL)
 consistent_bootstrap_test.py:55: 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
tools/data.py:34: in query_c1c2
    rows = list(session.execute(query))
cassandra/cluster.py:2618: in cassandra.cluster.Session.execute
    ???
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
 >    ???
E   cassandra.OperationTimedOut: errors={'127.0.0.1:9042': 'Client request timeout. See Session.execute[_async](timeout)'}, last_host=127.0.0.1:9042
 cassandra/cluster.py:4894: OperationTimedOut
{code}
Bug: Separating CQLSH credentials from the cqlshrc file
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 21/Sep/21 16:02
Resolved: 11/Oct/21 16:42

Currently, the CQLSH tool accepts credentials (username & password) from the following 3 places:
1. the command line parameter "-p"
2. the cqlshrc file
3. prompt the user

This is not ideal.
Credentials in the command line is a security risk, because it could be see by other users on a shared system.
The cqlshrc file is better, but still not good enough. Because the cqlshrc file is a config file, it's often acceptable to have it as a world readable file, and share it with other users. It also prevents user from having multiple sets of credentials, either for the same Cassandra cluster or different clusters.

To improve the security of CQLSH and make it secure by design, I propose the following changes:
 * Warn the user if a password is giving in the command line, and recommend them to use a credential file instead
 * Warn the user if credentials are present in the cqlshrc file and the cqlshrc file is not secure (e.g.: world readable or owned by a different user)
 * Deprecate credentials in the cqlshrc, and recommend the user to move them to a separate credential file. The aim is to not break anything at the moment, but eventually stop accepting credentials from the cqlshrc file.
 * Reject the credentials file if it's not secure, and tell the user how to secure it. Optionally, prompt the user for password if it's an interactive session. (Think how does OpenSSH handle insecure credential files)
Bug: Confusing ProtocolException msg Invalid or unsupported protocol version (4)
Status: Resolved
Priority: Normal
Resolution: Cannot Reproduce
Created: 09/Sep/21 21:49
Resolved: 10/Aug/22 01:43

The following warning was seen frequently after upgrading from 3.0.15 to 3.11.11 in the cassandra.log:
{noformat}
ProtocolException: Invalid or unsupported protocol version (4); supported versions are (3/v3, 4/v4, 5/v5-beta){noformat}
It is at best unclear, or maybe a bug in the code throwing this exception stating version '4' not supported but 4/v4 is.

from org/apache/cassandra/transport/ProtocolVersion.java

public static String invalidVersionMessage(int version)

{ return String.format("Invalid or unsupported protocol version (%d); supported versions are (%s)", version, String.join(", ", ProtocolVersion.supportedVersions())); }

We later found invalid IP addresses in the system.peers table and once removed, this exception went away.
Bug: Flaky replaceAliveHost test from hostreplacement.HostReplacementTest
Status: Resolved
Priority: Normal
Resolution: Duplicate
Created: 14/Sep/21 08:36
Resolved: 22/Jul/22 17:45

{{replaceAliveHost}} from {{org.apache.cassandra.distributed.test.hostreplacement.HostReplacementTest}} has failed number of times in different CircleCI builds in Java 8 and in Java 11. [The last failure|https://app.circleci.com/pipelines/github/k-rus/cassandra/14/workflows/3af46462-d162-4997-a49e-1ca10cd2392b/jobs/126/tests#failed-test-0]. The log is the same in different failures:
{code:java}
java.lang.RuntimeException: java.util.concurrent.TimeoutException
	at org.apache.cassandra.utils.Throwables.maybeFail(Throwables.java:70)
	at org.apache.cassandra.utils.FBUtilities.waitOnFutures(FBUtilities.java:476)
	at org.apache.cassandra.distributed.impl.AbstractCluster.close(AbstractCluster.java:850)
	at org.apache.cassandra.distributed.test.hostreplacement.HostReplacementTest.replaceAliveHost(HostReplacementTest.java:145)
	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)
Caused by: java.util.concurrent.TimeoutException
	at java.base/java.util.concurrent.CompletableFuture.timedGet(CompletableFuture.java:1886)
	at java.base/java.util.concurrent.CompletableFuture.get(CompletableFuture.java:2021)
	at org.apache.cassandra.utils.FBUtilities.waitOnFutures(FBUtilities.java:468)
{code}
Bug: Mockable Streaming
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 08/Sep/21 17:50
Resolved: 07/Oct/21 11:30

To support CEP-10 it is necessary to support alternative streaming implementations, so that execution may be controlled. The ticket encompasses two sub-tickets: firstly we make InetAddressAndPort extend InetAddress so that we may 2) introduce a cross-classloader API for establishing a streaming connection and sending data over it.
Bug: Make nodetool compactionstats and sstable_tasks consistent
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 18/Sep/21 17:44
Resolved: 14/Oct/21 11:23

Currently there is a difference in the output if {{nodetool compactionstats}} command and {{sstable_tasks}} virtual table (originally introduced by CASSANDRA-14457). They need to be aligned. The differences are:

 
||nodetool||VT||Comment||
|percentComplete|completion_ratio|column naming is different only|
|completed|progress|column naming is different only|
|compaction type|kind|column naming is different only|
|sstables|NA| |

Additionally, please, update necessary documentation.
Bug: Add number of sstables in a compaction to compactionstats output
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 11/Aug/21 18:00
Resolved: 22/Sep/21 16:41

It would be helpful to know at a glance how many sstables are involved in any running compactions. While this information can certainly be collected now, a user has to grab it from the debug logs. I think it would be helpful for some use cases to have this information straight from {{nodetool compactionstats}} and then if the actual sstables involved in the compactions are desired, dive into the debug.log for that. I think it would also be good to have this information in the output of {{nodetool compactionhistory}}.
Bug: DOC - num_tokens default shown as 256 but is 16 starting in 4.0
Status: Resolved
Priority: Normal
Resolution: Not A Problem
Created: 20/Sep/21 16:16
Resolved: 01/Jun/22 06:52

On [https://cassandra.apache.org/doc/latest/cassandra/configuration/cass_yaml_file.html#num_tokens,] the default for num_tokens is still shown as 256.  

However, I think it changed to 16 starting in 4.0.0.  Can you please check with the C* devs?  I was talking with a couple K8ssandra devs and we think the default changed since 3.11.x.  

Possibly the docs were updated on a branch but that PR has not yet been merged? Many thanks for looking into it.
Bug: Secondary indexes on primary key columns can miss some writes
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 19/Aug/21 11:17
Resolved: 24/Aug/21 17:22

Secondary indexes on primary key columns can miss some writes. For example, an update after a deletion won't create an index entry:
{code:java}
CREATE TABLE t (pk int, ck int, v int, PRIMARY KEY (pk, ck));
CREATE INDEX ON t(ck);
INSERT INTO t(pk, ck, v) VALUES (1, 2, 3); -- creates an index entry (right)
DELETE FROM t WHERE pk = 1 AND ck = 2; -- deletes the previous index entry (right)
UPDATE t SET v = 3 WHERE pk = 1 AND ck = 2; -- doesn't create a new index entry (wrong)
SELECT * FROM t WHERE ck = 2; -- doesn't find the row (wrong)
{code}
This happens because the update uses the {{LivenssInfo}} of the previously deleted row (see [here|https://github.com/apache/cassandra/blob/cassandra-3.0.25/src/java/org/apache/cassandra/index/internal/CassandraIndex.java#L439]). The same happens when updating an expired row:
{code:java}
CREATE TABLE t (pk int, ck int, v int, PRIMARY KEY (pk, ck));
CREATE INDEX ON t(ck);
UPDATE t USING TTL 1 SET v = 3 WHERE pk = 1 AND ck = 2; -- creates a non-expiring index entry (right)
-- wait for the expiration of the above row
SELECT * FROM t WHERE ck = 2; -- deletes the index entry (right)
UPDATE t SET v = 3 WHERE pk = 1 AND ck = 2; -- doesn't create an index entry (wrong)
SELECT * FROM t WHERE ck = 2; -- doesn't find the row (wrong)
{code}
I think that the fix for this is just using the {{getPrimaryKeyIndexLiveness}} in {{updateRow}}, as it's used in {{insertRow}}.

Another related problem is that {{getPrimaryKeyIndexLiveness}} uses [the most recent TTL in the columns contained on the indexed row fragment|https://github.com/apache/cassandra/blob/cassandra-3.0.25/src/java/org/apache/cassandra/index/internal/CassandraIndex.java#L519] as the TTL of the index entry, producing an expiring index entry that ignores the columns without TTL that are already present in flushed sstables. So we can find this other error when setting a TTL over flushed indexed data:
{code:java}
CREATE TABLE t(k1 int, k2 int, v int, PRIMARY KEY ((k1, k2)));
CREATE INDEX idx ON t(k1);
INSERT INTO t (k1, k2, v) VALUES (1, 2, 3);
-- flush
UPDATE t USING TTL 1 SET v=0 WHERE k1=1 AND k2=2; -- creates an index entry with TTL (wrong)
-- wait for TTL expiration
SELECT TTL(v) FROM t WHERE k1=1; -- doesn't find the row (wrong)
{code}
The straightforward fix is just ignoring the TTL of the columns for indexes on primary key components, so we don't produce expiring index entries in that case. The index entries will be eventually deleted during index reads, when we are sure that they are not pointing to any live data.
Bug: Allow DELETE and TRUNCATE to work on Virtual Tables if the implementation allows it
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 16/Jul/21 09:34
Resolved: 17/Sep/21 13:10

{{TRUNCATE}} statements are currently not supported by Virtual Tables. For some Virtual Tables it makes sense to allow it.

It can be done by adding a {{truncate}} method to the {{VirtualTable}} interface and calling that method from {{TruncateStatement}}. The default implementation of the method should be to fire an {{InvalidRequestException}} saying that truncate is not supported on that specific table.