av9ash/GitBugs huggingface dataset:
Bug: Enhance Zstd support in Cassandra with dictionaries
Status: In Progress
Priority: Normal
Created: 01/Oct/21 23:09

Currently Cassandra supports zstd compression. However, Zstd also supports dictionaries to enhance not only the compression ratio but also the speed. Dictionaries can show 3-4x savings. We should add support to train dictionaries, ideally per SSTable this will yield the maximum gains.
Bug: Upgrade Snappy version to support Apple M1
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 14/Oct/21 02:40
Resolved: 07/Jan/22 19:06

Some Unit test cases were failed in Apple M1:

 
{code:java}
[junit-timeout] Testcase: testTableOptions(org.apache.cassandra.cql3.validation.miscellaneous.OverflowTest): Caused an ERROR
[junit-timeout] SnappyCompressor.create() threw an error: java.lang.NoClassDefFoundError Could not initialize class org.xerial.snappy.Snappy
[junit-timeout] org.apache.cassandra.exceptions.ConfigurationException: SnappyCompressor.create() threw an error: java.lang.NoClassDefFoundError Could not initialize class org.xerial.snappy.Snappy
[junit-timeout] at org.apache.cassandra.schema.CompressionParams.createCompressor(CompressionParams.java:344)
[junit-timeout] at org.apache.cassandra.schema.CompressionParams.<init>(CompressionParams.java:211)
[junit-timeout] at org.apache.cassandra.schema.CompressionParams.fromMap(CompressionParams.java:124)
[junit-timeout] at org.apache.cassandra.cql3.statements.schema.TableAttributes.build(TableAttributes.java:110)
[junit-timeout] at org.apache.cassandra.cql3.statements.schema.TableAttributes.validate(TableAttributes.java:58)
[junit-timeout] at
....
...
..
 
{code}
 

Snappy-java added M1 support since 1.1.8.2.([https://github.com/xerial/snappy-java/pull/268).]

So  let's upgrade snappy-java dependency to the latest release 1.1.8.4.
Bug: CEP-15: (Accord) Transactions must be replicated to an optimal number of replicas
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 30/Oct/21 11:15
Resolved: 10/Jan/23 21:22

Today Accord sends the complete transaction to every shard. This is unnecessary, Accord should instead nominate a single primary shard to replicate the transaction, with the other shards receiving only the {{(txnId,primary shard key)}} tuple as part of PreAccept.
Bug: Improve backup / restore documentation
Status: Triage Needed
Priority: Normal
Created: 15/Dec/21 07:19

The page about backup and restore lacks description about how to restore data after snapshot or backup

Few statements at https://cassandra.apache.org/doc/latest/cassandra/operating/backups.html#restoring-from-incremental-backups-and-snapshots is far too little and does not actually show how to do that.
Bug: Fix test org.apache.cassandra.repair.RepairJobTest
Status: Resolved
Priority: Normal
Resolution: Duplicate
Created: 29/Oct/21 19:10
Resolved: 29/Oct/21 19:13

https://app.circleci.com/pipelines/github/dcapwell/cassandra/1062/workflows/3642831f-81d0-4c4f-8bb7-9444e11b58b4/jobs/7084

{code}
junit.framework.AssertionFailedError: 
Expecting:
 <10000L>
to be less than:
 <10000L> 
	at org.apache.cassandra.repair.RepairJobTest.testNoTreesRetainedAfterDifference(RepairJobTest.java:283)
	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}


The test seems to only fail on jdk11, but it consistently fails on jdk11
Bug: When data dir is not present, we fail as FileNotFound causes org.apache.cassandra.config.DatabaseDescriptor#tryGetSpace to fail
Status: Resolved
Priority: Normal
Resolution: Duplicate
Created: 02/Nov/21 20:43
Resolved: 02/Nov/21 20:48

When you download trunk and do ./bin/cassandra -f, this will fail on a fresh clone as “data” directory does not exist.  The failure happens in org.apache.cassandra.config.DatabaseDescriptor#tryGetSpace which throws a new error
 
{code}
throw new ConfigurationException("Unable check disk space in '" + dir + "'. Perhaps the Cassandra user does not have the necessary permissions")
{code}
Bug: Fix failing test: test_bootstrap_with_reset_bootstrap_state - bootstrap_test.TestBootstrap
Status: Resolved
Priority: Normal
Resolution: Duplicate
Created: 28/Oct/21 17:14
Resolved: 31/Jan/22 19:23

Both JDK8 and JDK11

Times out
{code:java}
bootstrap_test.py:483: 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
../env3.6/lib/python3.6/site-packages/ccmlib/node.py:895: in start
    node.watch_log_for_alive(self, from_mark=mark)
../env3.6/lib/python3.6/site-packages/ccmlib/node.py:664: in watch_log_for_alive
    self.watch_log_for(tofind, from_mark=from_mark, timeout=timeout, filename=filename)
../env3.6/lib/python3.6/site-packages/ccmlib/node.py:592: in watch_log_for
    head=reads[:50], tail="..."+reads[len(reads)-150:]))
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 

start = 1635437046.9280019, timeout = 120
msg = "Missing: ['127.0.0.1:7000.* is now UP'] not found in system.log:\n Head: \n Tail: ..."
node = 'node3'

    @staticmethod
    def raise_if_passed(start, timeout, msg, node=None):
        if start + timeout < time.time():
>           raise TimeoutError.create(start, timeout, msg, node)
E           ccmlib.node.TimeoutError: 28 Oct 2021 16:06:07 [node3] after 120.12/120 seconds Missing: ['127.0.0.1:7000.* is now UP'] not found in system.log:
E            Head: 
E            Tail: ...

../env3.6/lib/python3.6/site-packages/ccmlib/node.py:56: TimeoutError
{code}
Bug: CEP-11: Memtable API implementation
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 12/Oct/21 14:05
Resolved: 29/Apr/22 12:09

Pluggable memtable API as described in [CEP-11|https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-11%3A+Pluggable+memtable+implementations].

 

Initial version is already available in [this branch|https://github.com/datastax/cassandra/tree/memtable-api], and needs to be updated to the changes in trunk. Two additional features suggested by CEP reviewers are also to be implemented:
 * Sharding support: extending the memtable owner interface to supply suitable shard boundaries that split the owned token space and are in agreement with disk boundaries.
 * Shared read API with sstables: defining a common interface for reading partitions from memtables and sstables; this is to include filters to avoid unnecessary copying.
Bug: CEP-15: (Accord) Strict Serializability Verification
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 30/Oct/21 10:55
Resolved: 08/Nov/22 10:10

The in-tree verifier combines a Serializability verifier and per-key Linearizability verifier, but these combined do not demonstrate Strict Serializability - the Serializability verifier needs to be modified to operate directly on timestamps as well as the happens-before relations it uses currently.
Bug: Add flags to CircleCI generation script to setup the workflows
Status: In Progress
Priority: Normal
Created: 01/Nov/21 14:24

CASSANDRA-16882 modified the CircleCI config to contain two separate pairs of j8/j11 workflows. The {{pre-commit_tests}} workflows are meant for patches that are mostly read for commit, and they have a single approval step on the Circle GUI to run the most relevant tests. The {{separate_tests}} workflows are meant for intermediate commits and special cases such as fixing flaky tests, and every test group requires manual approval on the Circle GUI. Both pairs of workflows are always created, so every commit/push creates the four workflows. None of these workflows runs anything unless manually approved on the GUI, not even the build.

This ticket is a followup for those changes, and it aims to implement [this suggestion|https://lists.apache.org/thread/8bghc7ng18s83vd4m16ccpj89dy6bm7x] about having a script that enables the relevant workflows for each use case. I have modified the existing {{.circleci/generate.sh}} script to be able to generate different workflows.

The new {{-p}} flag generates only the pre-commit workflows, whereas the {{-s}} flag generates only the workflows with separate approval steps for each test job. Both flags can be used together to generate the two pairs of workflows ({{-ps}}, {{-sp}}, etc.). The default option is generating all the workflows, so users can decide what workflow are they going to use in the CircleCI GUI, after pushing their changes. We can easily change the workflows that are generated by default to use the single pair of workflows that we think is better.

Additionally, there is a {{-r}} flag that disables the first approval step of the generated workflows. For the {{separate_tests}} workflows it means that the build is automatically run, but the individual steps still need to be manually approved in the GUI. For the {{pre-commit_tests}} workflows, the {{-r}} flag will automatically run the build and the most relevant tests.

For example, users pushing a mostly ready patch and wanting to run the tests at maximum speed would probably want to generate their config file with {{.circleci/generate.sh -hpr}} ({{-h}} for HIGHRES config, see CASSANDRA-16871).
Bug: Upgrade to Logback 1.2.9 (security)
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 14/Dec/21 15:24
Resolved: 20/Jan/22 15:52

Logback 1.2.8 has been released with a fix for a potential vulnerability in its JNDI lookup.
 * [http://logback.qos.ch/news.html]
 * [https://jira.qos.ch/browse/LOGBACK-1591]

{quote}*14th of December, 2021, Release of version 1.2.8*
We note that the vulnerability mentioned in LOGBACK-1591 requires write access to logback's configuration file as a prerequisite.
* • In response to LOGBACK-1591, we have disabled all JNDI lookup code in logback until further notice. This impacts {{ContextJNDISelector}} and {{<insertFromJNDI>}} element in configuration files.
* Also in response to LOGBACK-1591, we have removed all database (JDBC) related code in the project with no replacement.

We note that the vulnerability mentioned in LOGBACK-1591 requires write access to logback's configuration file as a prerequisite. A successful RCE requires all of the following to be true:

* write access to logback.xml
* use of versions < 1.2.8
* reloading of poisoned configuration data, which implies application restart or scan="true" set prior to attack

Therefore and as an additional precaution, in addition to upgrading to version 1.2.8, we also recommend users to set their logback configuration files as read-only.
{quote}
This is not as bad as CVE-2021-44228 in Log4j <2.15.0 (Log4Shell), but should probably be fixed anyway.
Bug: readWriteDuringBootstrapTest - org.apache.cassandra.distributed.test.ring.BootstrapTest
Status: Resolved
Priority: Normal
Resolution: Resolved
Created: 11/Nov/21 17:05
Resolved: 13/Jul/22 02:10

The test was seen failing in both 
[CircleCI|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/1188/workflows/06afaf5b-6951-4b3d-8fbf-6ef2aef04e52/jobs/7025] and [Jenkins|https://jenkins-cm4.apache.org/job/Cassandra-4.0/267/testReport/junit/org.apache.cassandra.distributed.test.ring/BootstrapTest/readWriteDuringBootstrapTest/] lately.
Bug: Enhance SnakeYAML properties to be reusable outside of YAML parsing, support camel case conversion to snake case, and add support to ignore properties
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 19/Nov/21 19:57
Resolved: 23/Apr/22 03:18

SnakeYaml is rather limited in the “object mapping” layer, which forces our internal code to match specific patterns (all fields public and camel case); we can remove this restriction by leveraging Jackson for property lookup, and leaving the YAML handling to SnakeYAML
Bug: CEP-3: Guardrails
Status: Triage Needed
Priority: Normal
Created: 15/Nov/21 15:34

Implementation of guardrails as described in [CEP-3|https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-3%3A+Guardrails].

The goal of this feature is to have an easy way for operators to enforce system-wide soft and hard limits that ensure good practices, foster availability, and guard the system from wrong usage patterns.
Bug: CEP-15: (Accord) Transaction outcomes must be replicated to an optimal number of replicas
Status: Triage Needed
Priority: Normal
Created: 30/Oct/21 11:20

Transaction outcomes that are defined by the transaction should not be replicated, and outcomes that are computed from existing records (and as such were not replicated as part of the original transaction) should only be replicated to a single primary shard. This complicates execution, however, without MVCC as the shards from which we had to read the original value cannot delete their state until they know the updated value is replicated durably. One simple option here might be to replicate any new values only to those shards on whom the value's computation depended, so that any shard that receives this new value is safely able to report what the outcome of the transaction is (but is unable to participate in a recomputation of that part of the transaction).
Bug: CEP-15: (Accord) Transaction dependencies must include at most the txnId
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 30/Oct/21 11:22
Resolved: 17/Aug/22 08:58

Today we must ship the entire transaction as part of the dependencies we share. This is very costly. We may ship only the {{txnId,primary shard key}} if we modify recovery to first discover the original transaction, or invalidate it if it cannot be found.
Bug: CEP-15: (Accord) Liveness / Repair
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 30/Oct/21 10:57
Resolved: 28/Jun/22 09:42

Accord requires replicas apply a consistent prefix of agreed operations, and permits many operations to be in-flight and depending on each other. These both benefit from strong liveness properties to ensure the system is always able to make rapid progress. To this end, we will introduce a gossip-like mechanism for communicating knowledge about the replication status of known transactions. Nodes will frequently reconcile their knowledge of each other’s knowledge with each other, so that the status of a transaction on other nodes can be rapidly determined.
Bug: Implement startup check to prevent Cassandra start to spread zombie data
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 01/Dec/21 13:05
Resolved: 29/Apr/22 11:29

As already discussed on ML, it would be nice to have a service which would periodically write timestamp to a file signalling it is up / running.

Then, on the startup, we would read this file and we would determine if there is some table which gc grace is behind this time and we would fail the start so we would prevent zombie data to be likely spread around a cluster.

https://lists.apache.org/thread/w4w5t2hlcrvqhgdwww61hgg58qz13glw
Bug: Introduce separate rate limiting settings for entire SSTable streaming
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 25/Oct/21 20:31
Resolved: 10/Nov/21 18:37

With the introduction of entire SSTable streaming, it is desirable to introduce new settings for the rate limit for entire SSTable streaming operations.

Currently, regular streaming and SSTable streaming are rate limited by the same setting. However, zero-copy streaming reduces load in the JVM and we can have a setting specifically for this use case.
Bug: Harden resource management on SSTable components to prevent further leaks
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 29/Nov/21 16:22
Resolved: 01/Dec/21 17:38

We've seen resource leaks pop up w/histogram overflows repeatedly; the code in {{BigTableWriter.openEarly()}} and {{BigTableWriter.openFinal()}} doesn't appropriately catch and handle any exceptions during creation before things are registered with a {{LifecycleTransaction}} so any errors there will leak.

We should clean that up.
Bug: DebuggableThreadPoolExecutor does not propagate client warnings
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 28/Oct/21 09:25
Resolved: 19/Nov/21 01:33

Extracted this as a separate ticket per discussion on CASSANDRA-17044

The problem is in {{DebuggableThreadPoolExecutor}} - it does not propagate executor locals to the thread when tracing is disabled. It is probably expected that we propagate the state if at least one executor local is defined, but we only check for tracing and completely ignore client warnings.

The attached PR fixes the problem, adds some tests and reverts a workaround for client warnings in some schema alteration statements implemented in CASSANDRA-16296 (described below).

----

h4. Old description - still valid, but this is just a manifestation of the problem rather than the problem itself
This seemed to be screwed a bit. In just two schema alteration statements we collect client warnings which are captured during the transformation into a local collection. 

I guess it is done that way because the transformation is being executed in a different stage (migration) and client warnings collected in that stage are not present in the stage where the query is executed. 

Then, the client warnings are retrieved using {{clientWarnings}} method and added to the captured client warnings in the stage which is executing the query. 

This mechanism was implemented only in two schema alteration statements. It is possible that for other ones the client warnings can simply get lost.
Bug: Add logging and metrics to Index Summary Redistribution
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 12/Oct/21 16:33
Resolved: 13/Oct/21 13:31

We don't have much visibility into the performance / impact / time taken on index summary redistribution, either in memory impact or time to execute. We should add some metrics and slightly tweak the logging around that to make it more useful.
Bug: SchemaCQLHelperTest methods can be simplified
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 02/Dec/21 17:37
Resolved: 15/Dec/21 17:51

{{SchemaCQLHelperTest}} is used during a snapshot to generate the {{schema.cql}} file. The methods accept the following paramaters: {{includeDroppedColumns}}, {{internals}} and {{ifNotExists}}.
Those parameters are in practice always set to true by the calling code and therefore can be removed.
Bug: Guardrails prototype
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 15/Nov/21 15:58
Resolved: 03/Dec/21 15:30

The purpose of this ticket is creating an initial implementation of the guardrails framework, as well as adding a few simple guardrails using this framework.

To keep things easy, this initial implementation would only support guardrails that are triggered on the coordinator, and they would be dynamically updatable only through JMX.

Once we have this initial framework ready in a feature branch we can have multiple tickets addressing all the things that would have been left out of the scope of this ticket, such as:

* Dynamic updates through virtual tables
* Being able to notify about guardrails triggered on replicas
* Using custom exceptions other than {{InvalidRequestException}}.
* Porting existing limits to use the new guardrails framework
* Adding new guardrails beyond the initial ones

The reason for having this simpler prototype is that it will give us a common ground to parallelize work on the parts mentioned above.
Bug: Limit the maximum hints size per host
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 12/Nov/21 22:12
Resolved: 11/Feb/22 01:21

The hints system defines a time window, i.e. max_hint_window_in_ms, to store the hints. 

It defines no limit on how much data can be kept during the time window. The hints can grow excessively and make the node running out of disk. In such scenario, the operators have to truncate the hints manually.

I'd propose that in addition to the conventional hints window, operators should be able to define the maximum hints size per host, i.e. max_hints_size_per_host_in_mb, to provide an another layer of protection. A node stops to store hints for the down node whenever it reaches to the time cap or the size cap. In order to not surprise the users, the config should be disabled by default. It should also be configurable via JMX.
Bug: Add support for String contatenation through the "+" operator
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 06/Dec/21 14:07
Resolved: 11/Feb/22 14:48

Since 4.0, Cassandra support operations on numeric types and on some temporal types.
We should add support for string concatenations through the {{+}} operator.

+Additional information for newcomers:+

Cassandra has 2 string types: {{Text}} ({{UTF8Type}})  and ascii ({{AsciiType}}) both are sub-classes of ({{StringType}}). In order to add support for string concatenation you will need to add a new method to {{StringType}} and modify {{OperationFcts}} to add the new functions (one for each combination of types: ascii/ascii, ascii/text, text/ascii and text/text).

The unit test should be added to {{OperationFctsTest}}.
To allow for concatenating constants (eg: SELECT v1 + ' ' + v2 FROM ...) you will need to add a {{getPreferedTypeFor}} method to {{org.apache.cassandra.Constants.Type.STRING}} that determine the constant type based on its content (ascii or not).
Bug: Flaky RecomputingSupplierTest
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 24/Nov/21 11:05
Resolved: 03/Dec/21 10:41

See https://ci-cassandra.apache.org/job/Cassandra-4.0/293/testReport/junit/org.apache.cassandra.utils/RecomputingSupplierTest/recomputingSupplierTest/

{noformat}
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.RecomputingSupplier.get(RecomputingSupplier.java:110)
	at org.apache.cassandra.utils.RecomputingSupplierTest.recomputingSupplierTest(RecomputingSupplierTest.java:120)
	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)
{noformat}
Bug: Refactor normal/preview/IR repair to standardize repair cleanup and error handling of failed RepairJobs
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 27/Oct/21 15:05
Resolved: 13/Nov/21 01:03

Right now we have 3 different implementations of repair: normal, preview, and incremental (IR); all 3 handle RepairJob failures differently and offer different state cleanup.  To make sure that we consistently handle errors the same way and cleanup, we should move these responsibilities outside of the repair task itself and move these into common APIs and move some logic into the repair coordination its self.

This work relates with CASSANDRA-15399 as special handling each task makes the work more complex.
Bug: Flaky GrantAndRevokeTest
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 29/Nov/21 09:33
Resolved: 30/Nov/21 05:54

See [here|https://ci-cassandra.apache.org/job/Cassandra-trunk/869/testReport/junit/org.apache.cassandra.auth/GrantAndRevokeTest/testGrantedKeyspace_cdc/]

{noformat}
junit.framework.AssertionFailedError: Expected error message to contain 'User user has no MODIFY permission on <table cql_test_keyspace_alt.table_06> or any of its parents', but got 'You do not have access to this datacenter (datacenter1)'
	at org.apache.cassandra.cql3.CQLTester.assertMessageContains(CQLTester.java:1782)
	at org.apache.cassandra.cql3.CQLTester.assertInvalidThrowMessage(CQLTester.java:1721)
	at org.apache.cassandra.cql3.CQLTester.assertUnauthorizedQuery(CQLTester.java:1794)
	at org.apache.cassandra.auth.GrantAndRevokeTest.testGrantedKeyspace(GrantAndRevokeTest.java:64)
{noformat}