av9ash/GitBugs huggingface dataset:
Bug: Guardrail for the number of tables is not working
Status: Triage Needed
Priority: Urgent
Created: 21/Nov/23 19:15

Hi, 

We installed Cassandra 4.1.3 and we got the following warning when creating more than 150 tables: 
{code:java}
WARN  [Native-Transport-Requests-6] 2023-11-21 18:35:24,585 CreateTableStatement.java:421 - Cluster already contains 161 tables in 6 keyspaces. Having a large number of tables will significantly slow down schema dependent cluster operations. {code}

I tried to disable "table_count_warn_threshold" by setting its value to "-1" but that did not work. 

Then I tried to set the guardrail for number of tables to "-1" to disable the above but did not work as well. It seems there is no way to disable checking the number of tables. 

Also,  I tried to set "tables_warn_threshold" to a value less than "tables_count_warn_threshold", it seems Cassandra always uses "tables_count_warn_threshold" when throwing the warning. 

*Two issues in Cassandra 4.1.3:* 
1- There should be a way to disable this feature. Either by setting the guardrail parameter to -1 or setting tables_count_warn_threshold to -1. 


2- The guardrail for number of tables should overwrite tables_count_warn_threshold because I always get the following warning when I try to increase the number of tables: 
{code:java}
WARN  [main] 2023-11-21 18:26:16,988 YamlConfigurationLoader.java:427 - [keyspace_count_warn_threshold, table_count_warn_threshold] parameters have been deprecated. They have new names and/or value format; For more information, please refer to NEWS.txt {code}
Bug: Security vulnerabilities in Netty in cassandra netty-all-4.1.58.Final.jar 
Status: Resolved
Priority: Urgent
Resolution: Duplicate
Created: 01/Dec/23 09:49
Resolved: 01/Dec/23 11:56

CVE - 
|CVE-2021-21290 (BDSA-2021-0311)|
|CVE-2021-21295 (BDSA-2021-0589)|
|CVE-2021-21409 (BDSA-2021-0828)|
|CVE-2021-37136 (BDSA-2021-2832)|
|CVE-2021-37137 (BDSA-2021-2831)|
|CVE-2021-43797 (BDSA-2021-3741)|
|CVE-2022-24823|
|CVE-2022-41881 (BDSA-2022-3559)|
|CVE-2023-34462 (BDSA-2023-1556)|
Bug: Security vulnerabilities in google-guava In Cassandra (CVE-2023-2976)
Status: Resolved
Priority: Urgent
Resolution: Duplicate
Created: 01/Dec/23 10:14
Resolved: 01/Dec/23 11:51

Security vulnerabilities in google-guava In Cassandra (CVE-2023-2976)

Component name - google-guava
Component version name - v27.0
CVE - CVE-2023-2976 (BDSA-2016-1748)
CVSS - 7.1 (High)

Archive Context and Path
apache-cassandra/lib/guava-27.0-jre.jar
Bug: Security vulnerabilities in SnakeYAML In Cassandra (CVE-2022-1471)
Status: Resolved
Priority: Urgent
Resolution: Duplicate
Created: 01/Dec/23 11:12
Resolved: 01/Dec/23 11:51

Component name - SnakeYAML
Component version name - 1.26
CVE - CVE-2022-1471 (BDSA-2022-3447)
CVSS - 9.8 (Critical)

Archive Context and Path
apache-cassandra/lib/snakeyaml-1.26.jar
Bug: Remove dependency on bundled Harry jar
Status: Resolved
Priority: Urgent
Resolution: Fixed
Created: 24/Nov/23 12:51
Resolved: 01/Dec/23 08:04

For expediency, we temporarily added a snapshot jar to the source tree, {{lib/harry-core-0.0.2-CASSANDRA-18768.jar}}. We should remove this as soon as the next Harry release is published.
Bug: Speculative read retries and multiple replica responses driving up latencies on CL ONE queries with RF 5 keyspace in C* 4.0.7
Status: Triage Needed
Priority: Urgent
Created: 22/Nov/23 04:47

A Cassandra 4.0.7 cluster is experiencing very high cpu utilization and extremely high latencies when certain partitions become hot.

This is occurring on a keyspace with a Replication Factor of 5 and a Consistency Level of ONE.  There are ~10 data drives per node, which is why you'll see multiple sstables read in some traces because the data is distributed round-robin among the drives.
All queries are single-partition queries.

I'm sure we haven't identified every partition that this occurs for, but at least for the couple that we found, it seems we're hitting at least 3 of the 5 replicas in many cases and doing a lot of speculative retry, even though the CL is ONE.  We've kicked off some count queries just to capture a trace output for a couple of the partitions that are known to cause issues, attached to the Jira.  When any of these partitions become hot, it pegs the cpu, drives up latencies, and causes a lot of timeouts.
I assume this could be a bug related to the RF 5 keyspace as we'd probably have seen this already with RF 3 keyspaces, but I have yet to test changing the RF to 3 to see if that resolves the issue.

The schema for the table with the problematic partitions:

{code:java}
CREATE TABLE v2metadata.tag_values_fresh (
  metric_name ascii,
  tag_names ascii,
  shard_id tinyint,
  v2namespace ascii,
  tag_values ascii,
  metric_id blob,
  timestamp_mins_last varint,
  PRIMARY KEY ((metric_name, tag_names, shard_id), v2namespace, tag_values)
) WITH CLUSTERING ORDER BY (v2namespace ASC, tag_values ASC)
  AND additional_write_policy = '99p'
  AND bloom_filter_fp_chance = 0.01
  AND caching = {'keys': 'ALL', 'rows_per_partition': 'NONE'}
  AND cdc = false
  AND comment = ''
  AND compaction = {'class': 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy', 'max_threshold': '32', 'min_threshold': '4', 'unchecked_tombstone_compaction': 'true'}
  AND compression = {'chunk_length_in_kb': '64', 'class': 'org.apache.cassandra.io.compress.LZ4Compressor'}
  AND crc_check_chance = 1.0
  AND default_time_to_live = 864000
  AND extensions = {}
  AND gc_grace_seconds = 10800
  AND max_index_interval = 2048
  AND memtable_flush_period_in_ms = 0
  AND min_index_interval = 128
  AND read_repair = 'BLOCKING'
  AND speculative_retry = '99p';
{code}
Bug: Index.Group is incorrectly unregistered from the SecondaryIndexManager
Status: Resolved
Priority: Urgent
Resolution: Fixed
Created: 04/Oct/23 09:49
Resolved: 18/Oct/23 19:43

An Index.Group is removed from the SecondaryIndexManager during unregisterIndex if it contains no indexes after the index is unregistered.

The code for removing the group uses the wrong key to remove the group from the indexGroups map. It is using the group object rather than the group name that is used as the key in the map.

This means that the group is not added again if a new index is registered using that group. The knock on from this is that the StorageAttachedIndexGroup unregisters itself from the Tracker when it has no indexes after an index is removed. The same group with no tracker is then used for new indexes. This group then receives no notifications about sstable or memtable updates. The ultimate side effect of this is that, memtables are not released, resulting in memory leaks and indexes are not updated with new sstables and their associated index files.
Bug: TCM: Allow unknown nodes during discovery
Status: Resolved
Priority: High
Resolution: Fixed
Created: 12/Oct/23 07:45
Resolved: 15/Jan/24 09:47

      * avoid discovered.addAll(DatabaseDescriptor.getSeeds()) when starting discovery to exclude them from the final result
      * add responded node to discovered set, even if it responds with an empty set
      * Implement a simple simulation for discovery that does not involve setting up entire clusters
      * Allow _any_ seed to start up first
Bug: Bring Harry into OSS Cassandra tree
Status: Resolved
Priority: High
Resolution: Fixed
Created: 20/Dec/23 14:03
Resolved: 23/Dec/23 14:18

This patch introduces Harry into tree. 

_No_ modifications were made to Harry code, so technically our tree has already relied on it. The intention to introduce Harry to tree to lower the entry barrier and allow quicker developer turnarounds.

CI results attached; all tests are green. Python tests are skipped because this patch does not make any changes to production code, it's all testonly.
Bug: Queries with multi-column replica-side filtering can miss rows
Status: Open
Priority: Normal
Created: 07/Nov/23 17:28

{{SELECT}} queries with multi-column replica-side filtering can miss rows if the filtered columns are spread across out-of-sync replicas. This dtest reproduces the issue:
{code:java}
@Test
public void testMultiColumnReplicaSideFiltering() throws IOException
{
    try (Cluster cluster = init(Cluster.build().withNodes(2).start()))
    {
        cluster.schemaChange(withKeyspace("CREATE TABLE %s.t (k int PRIMARY KEY, a int, b int)"));

        // insert a split row
        cluster.get(1).executeInternal(withKeyspace("INSERT INTO %s.t(k, a) VALUES (0, 1)"));
        cluster.get(2).executeInternal(withKeyspace("INSERT INTO %s.t(k, b) VALUES (0, 2)"));

        String select = withKeyspace("SELECT * FROM %s.t WHERE a = 1 AND b = 2 ALLOW FILTERING");
        Object[][] initialRows = cluster.coordinator(1).execute(select, ALL);
        assertRows(initialRows, row(0, 1, 2)); // not found!!
    }
}
{code}
This edge case affects queries using {{ALLOW FILTERING}} or any index implementation.

It affects all branches since multi-column replica-side filtering queries were introduced, long before 3.0.

The protection mechanism added by CASSANDRA-8272/8273 won't deal with this case, since it only solves single-column conflicts where stale rows could resurrect. This bug however doesn't resurrect data, it can only miss rows while the replicas are out-of-sync.
Bug: apt-key deprecation, replace with gpg --dearmor in the docs.
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 28/Nov/23 12:13
Resolved: 03/Apr/24 22:59

the command `apt-key` is deprecated and soon to be removed, especially on Ubuntu.
the directory `/usr/share/keyrings` for shared keys are also being removed.

I suggest to convert the docs from
{code:java}
curl https://downloads.apache.org/cassandra/KEYS | sudo apt-key add - {code}
to a simpler command:
{code:java}
curl https://downloads.apache.org/cassandra/KEYS | sudo gpg --dearmor -o /etc/apt/keyrings/cassandra-archive-keyring.gpg {code}
The path `/etc/apt/keyrings` doesn't exists by default on Ubuntu 20.04 but it does on 22.04.



I also suggest to add the source.list.d text from 
{code:java}
$ echo "deb https://debian.cassandra.apache.org 42x main" | sudo tee -a /etc/apt/sources.list.d/cassandra.sources.list

deb https://debian.cassandra.apache.org 42x main{code}
to 
{code:java}
$ echo "deb [signed-by=/etc/apt/keyrings/cassandra-archive-keyring.gpg] https://debian.cassandra.apache.org 42x main" | sudo tee -a /etc/apt/sources.list.d/cassandra.sources.list

deb [signed-by=/etc/apt/keyrings/cassandra-archive-keyring.gpg] https://debian.cassandra.apache.org 42x main {code}
I have made a [PR|https://github.com/apache/cassandra/pull/2936]

I have tested the gpg --dearmor on a VM with Ubuntu 22.04 myself recently and it works just fine.
Bug: Test Failure: pushed_notifications_test.TestPushedNotifications.test_move_single_node_localhost
Status: Open
Priority: Normal
Created: 22/Dec/23 07:48

https://app.circleci.com/pipelines/github/jacek-lewandowski/cassandra/1252/workflows/234ccc92-65f2-4adb-a68a-a5505398f4d0/jobs/63791/tests

{noformat}
AssertionError: assert 'MOVED_NODE' == 'NEW_NODE'
  - NEW_NODE
  + MOVED_NODE
self = <pushed_notifications_test.TestPushedNotifications object at 0x7f4f60868dd0>

    @pytest.mark.no_vnodes
    def test_move_single_node_localhost(self):
        """
        Test that we don't get NODE_MOVED notifications from nodes other than the local one,
        when rpc_address is set to localhost (127.0.0.1) Pre 4.0.
        Test that we get NODE_MOVED notifications from nodes other than the local one,
        when rpc_address is set to localhost (127.0.0.1) Post 4.0.
        @jira_ticket  CASSANDRA-10052
        @jira_ticket  CASSANDRA-15677
    
        To set-up this test we override the rpc_address to "localhost (127.0.0.1)" for all nodes, and
        therefore we must change the rpc port or else processes won't start.
        """
        cluster = self.cluster
        cluster.populate(3)
    
        self.change_rpc_address_to_localhost()
    
        cluster.start()
    
        waiters = [NotificationWaiter(self, node, ["TOPOLOGY_CHANGE"])
                   for node in list(self.cluster.nodes.values())]
    
        # The first node sends NEW_NODE for the other 2 nodes during startup, in case they are
        # late due to network delays let's block a bit longer
        logger.debug("Waiting for unwanted notifications...")
        waiters[0].wait_for_notifications(timeout=30, num_notifications=2)
        waiters[0].clear_notifications()
    
        logger.debug("Issuing move command....")
        node1 = list(self.cluster.nodes.values())[0]
        node1.move("123")
    
        version = self.cluster.cassandra_version()
        for waiter in waiters:
            logger.debug("Waiting for notification from {}".format(waiter.address,))
            notifications = waiter.wait_for_notifications(30.0)
            if version >= '4.0':
                # CASSANDRA-15677 Post 4.0 we'll get the notifications. Check that they are for the right node.
                assert 1 == len(notifications), notifications
                notification = notifications[0]
                change_type = notification["change_type"]
                address, port = notification["address"]
>               assert "MOVED_NODE" == change_type
E               AssertionError: assert 'MOVED_NODE' == 'NEW_NODE'
E                 - NEW_NODE
E                 + MOVED_NODE

pushed_notifications_test.py:163: AssertionError
{noformat}
Bug: Storage Attached Indexes (Phase 3)
Status: Open
Priority: Normal
Created: 21/Dec/23 23:04

As 5.0 moves toward GA, this epic will serve as a place to organize our work around SAI for the next major release, which I'll call 5.1 for now.

New features, performance improvements, and usability enhancements are all on the table, and it is very likely that at least minor enhancements to the on-disk format will occur. This will bring the versioning hooks (see {{OnDiskFormat}} and friends) we've worked on to this point into focus.
Bug: ci job to build and push new in-tree docker images when dockerfile changes
Status: Open
Priority: Normal
Created: 16/Oct/23 15:07

The dockerfiles under .build/docker are now and are deployed by file md5sum.
(There is no "latest").

in-tree scripts will have to build these images on-the-fly if they are not available to pull from dockerhub.

Automatically building and pushing them to dockerhub whenever they change will save a lot of resources and time in tests/CI.
Bug: An SAI-specific mechanism to ensure consistency isn't violated for multi-column (i.e. AND) queries at CL > ONE
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 09/Nov/23 20:38
Resolved: 29/Feb/24 21:06

CASSANDRA-19007 is going to be where we add a guardrail around filtering/index queries that use intersection/AND over partially updated non-key columns. (ex. Restricting one clustering column and one normal column does not cause a consistency problem, as primary keys cannot be partially updated.) This issue exists to attempt to fix this specifically for SAI in 5.0.x, as Accord will (last I checked) not be available until the 5.1 release.

The SAI-specific version of the originally reported issue is this:

{noformat}
try (Cluster cluster = init(Cluster.build(2).withConfig(config -> config.with(GOSSIP).with(NETWORK)).start()))
        {
            cluster.schemaChange(withKeyspace("CREATE TABLE %s.t (k int PRIMARY KEY, a int, b int)"));
            cluster.schemaChange(withKeyspace("CREATE INDEX ON %s.t(a) USING 'sai'"));
            cluster.schemaChange(withKeyspace("CREATE INDEX ON %s.t(b) USING 'sai'"));

            // insert a split row
            cluster.get(1).executeInternal(withKeyspace("INSERT INTO %s.t(k, a) VALUES (0, 1)"));
            cluster.get(2).executeInternal(withKeyspace("INSERT INTO %s.t(k, b) VALUES (0, 2)"));

        // Uncomment this line and test succeeds w/ partial writes completed...
        //cluster.get(1).nodetoolResult("repair", KEYSPACE).asserts().success();

            String select = withKeyspace("SELECT * FROM %s.t WHERE a = 1 AND b = 2");
            Object[][] initialRows = cluster.coordinator(1).execute(select, ConsistencyLevel.ALL);
            assertRows(initialRows, row(0, 1, 2)); // not found!!
        }
{noformat}

To make a long story short, the local SAI indexes are hiding local partial matches from the coordinator that would combine there to form full matches. Simple non-index filtering queries also suffer from this problem, but they hide the partial matches in a different way. I'll outline a possible solution for this in the comments that takes advantage of replica filtering protection and the repaired/unrepaired datasets...and attempts to minimize the amount of extra row data sent to the coordinator.
Bug: Test Failure: org.apache.cassandra.db.commitlog.CommitlogShutdownTest failed on trunk
Status: Open
Priority: Normal
Created: 27/Nov/23 11:21

{noformat}
java.lang.AssertionError
	at org.junit.Assert.fail(Assert.java:86)
	at org.junit.Assert.assertTrue(Assert.java:41)
	at org.junit.Assert.assertTrue(Assert.java:52)
	at org.apache.cassandra.db.commitlog.CommitlogShutdownTest.testShutdownWithPendingTasks(CommitlogShutdownTest.java:96)
	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)
	at java.base/java.lang.reflect.Method.invoke(Method.java:566)
	at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
	at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
	at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
	at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
	at org.jboss.byteman.contrib.bmunit.BMUnitRunner$10.evaluate(BMUnitRunner.java:393)
	at org.jboss.byteman.contrib.bmunit.BMUnitRunner$6.evaluate(BMUnitRunner.java:263)
	at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
	at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
	at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
	at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
	at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
	at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
	at org.jboss.byteman.contrib.bmunit.BMUnitRunner$1.evaluate(BMUnitRunner.java:97)
	at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
	at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
	at com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:69)
	at com.intellij.rt.junit.IdeaTestRunner$Repeater$1.execute(IdeaTestRunner.java:38)
	at com.intellij.rt.execution.junit.TestsRepeater.repeat(TestsRepeater.java:11)
	at com.intellij.rt.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:35)
	at com.intellij.rt.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:232)
	at com.intellij.rt.junit.JUnitStarter.main(JUnitStarter.java:55)
{noformat}

Manual testing to confirm issues found by CircleCI when testing CASSANDRA-18464. Run with Java 11 / IntelliJ
Bug: Metadata Loss caused by unchecked rename column when upgrading from 2.x to 3.0.29
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 24/Oct/23 17:14
Resolved: 09/Jan/25 22:59

After migrating data from 2.1.22 (released 2022-06-17) to 3.0.29 (released 2023-05-05), if user performs a rename operation to rename the primary key to an existing column, it will succeed, and the original column will get lost permanently.
h1. Reproduce

Start up single cassandra node 2.1.22

Start up *cassandra-cli*
{code:java}
bin/cassandra-cli {code}
Execute the following commands using cassandra-cli interface
{code:java}
create keyspace test with strategy_options = {replication_factor:1} and placement_strategy = 'org.apache.cassandra.locator.SimpleStrategy';

use test;

create column family foos 
with column_type = 'Standard' 
and comparator = 'BytesType'
and key_validation_class = 'UTF8Type' 
and column_metadata = [{column_name: '2f', validation_class: 'UTF8Type'}]; {code}
Stop the daemon
{code:java}
bin/nodetool -h ::FFFF:127.0.0.1 stopdaemon {code}
Upgrade, start up new version, start up cqlsh with *bin/cqlsh*
{code:java}
cqlsh> desc test.foos ;
CREATE TABLE test.foos (
    key text PRIMARY KEY,
    "2f" text
) WITH COMPACT STORAGE
    AND bloom_filter_fp_chance = 0.01
    AND caching = {'keys': 'ALL', 'rows_per_partition': 'NONE'}
    AND comment = ''
    AND compaction = {'class': 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy', 'max_threshold': '32', 'min_threshold': '4'}
    AND compression = {'chunk_length_in_kb': '64', 'class': 'org.apache.cassandra.io.compress.LZ4Compressor'}
    AND crc_check_chance = 1.0
    AND dclocal_read_repair_chance = 0.1
    AND default_time_to_live = 0
    AND gc_grace_seconds = 864000
    AND max_index_interval = 2048
    AND memtable_flush_period_in_ms = 0
    AND min_index_interval = 128
    AND read_repair_chance = 0.0
    AND speculative_retry = 'NONE';

cqlsh> ALTER TABLE test.foos RENAME key TO "2f";
cqlsh> desc test.foos ;
CREATE TABLE test.foos (
    "2f" text PRIMARY KEY
) WITH COMPACT STORAGE
    AND bloom_filter_fp_chance = 0.01
    AND caching = {'keys': 'ALL', 'rows_per_partition': 'NONE'}
    AND comment = ''
    AND compaction = {'class': 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy', 'max_threshold': '32', 'min_threshold': '4'}
    AND compression = {'chunk_length_in_kb': '64', 'class': 'org.apache.cassandra.io.compress.LZ4Compressor'}
    AND crc_check_chance = 1.0
    AND dclocal_read_repair_chance = 0.1
    AND default_time_to_live = 0
    AND gc_grace_seconds = 864000
    AND max_index_interval = 2048
    AND memtable_flush_period_in_ms = 0
    AND min_index_interval = 128
    AND read_repair_chance = 0.0
    AND speculative_retry = 'NONE';

cqlsh> SELECT * FROM test.foos ;
 2f
----

(0 rows) {code}
h1. Root Cause

The root cause is a missing check for the existing column when the table comparator from the old version is BytesType.

I have uploaded the data dir, use it to start up 3.0.29 and execute the commands will reproduce this bug.
Bug: Record commit timestamp - fix data loss when dropping and recreating a column
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 25/Oct/23 16:34
Resolved: 27/Nov/24 10:38

Drop column transformation is replayed with the current timestamp so the column appears to be dropped when the node starts regardless of its real drop time.

As a solution to this problem I propose recording the timestamp of the transformation, guaranteeing that it is always greater than a timestamp of any previously committed transformation. Such timestamp is passed to the execute method of the transformation so that the transformation code can make use of it, increasing its "purity".