av9ash/GitBugs huggingface dataset:
Bug: Cassandra 3.11.13 has CVE-2021-43818  and CVE-2022-2309
Status: Resolved
Priority: Normal
Resolution: Invalid
Created: 05/Aug/22 03:24
Resolved: 05/Aug/22 10:49

HI Team,

 

The latest version of Cassandra 3.11.13 has below Security Vulnerabilities:
|CVE-2022-2309|python|high|lxml|3.2.1|UNKNOWN|fixed in 4.9.1|NULL Pointer Dereference allows attackers to cause a denial of service (or application crash). This only applies when lxml is used together with libxml2 2.9.10 through 2.9.14. libxml2 2.9.9 and earlier are not affected. It allows triggering crashes through forged input data, given a vulnerable code sequence in the application. The vulnerability is caused by the iterwalk function (also used by the canonicalize function). Such code shouldn\'t be in wide-spread use, given that parsing + iterwalk would usually be replaced with the more efficient iterparse function. However, an XML converter that serialises to C14N would also be vulnerable, for example, and there are legitimate use cases for this code sequence. If untrusted input is received (also remotely) and processed via iterwalk function, a crash can be triggered.|
|CVE-2021-43818| python|high|lxml|3.2.1| |fixed in 4.6.5|lxml is a library for processing XML and HTML in the Python language. Prior to version 4.6.5, the HTML Cleaner in lxml.html lets certain crafted script content pass through, as well as script content in SVG files embedded using data URIs. Users that employ the HTML cleaner in a security relevant context should upgrade to lxml 4.6.5 to receive a patch. There are no known workarounds available.|
Bug: C* 4.0.5 RPM installation fails due to JRE 8/11 fix for CASSANDRA-17669
Status: Resolved
Priority: Normal
Resolution: Duplicate
Created: 02/Aug/22 12:02
Resolved: 02/Aug/22 12:40

Trying to install cassandra 4.0.5 results in the following error on centos/redhat7



yum upgrade cassandra
Loaded plugins: changelog, remove-with-leaves
Resolving Dependencies
--> Running transaction check
---> Package cassandra.noarch 0:4.0.1-1 will be updated
--> Processing Dependency: cassandra = 4.0.1-1 for package: cassandra-tools-4.0.1-1.noarch
---> Package cassandra.noarch 0:4.0.5-1 will be an update
Error: Invalid version flag: or
 

Issue comes from this commit

[https://github.com/apache/cassandra/commit/cd0a40d09e5c029e3cac260ecf4cb3dc02deabc7]

Requirement being 

Requires: (jre-1.8.0 or jre-11)

but _or_ is a feature added only in RHEL 8 or in rpm package version 4.13 + 

[https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/packaging_and_distributing_software/new-features-in-rhel-8_packaging-and-distributing-software#assembly_support-for-boolean-dependencies_new-features-in-rhel-8]

I think there should be dependency on newer version of rpm, or change the requirement
Bug: Seed docs are out of date
Status: Triage Needed
Priority: Normal
Created: 29/Jul/22 17:44

The [FAQ|https://cassandra.apache.org/doc/latest/cassandra/faq/index.html#are-seeds-SPOF] states
{quote}
The ring can operate or boot without a seed
{quote}

This has not been true since Cassandra 3.6 when CASSANDRA-10134 required nodes to complete a "shadow" gossip round or specify the undocumented ```cassandra.allow_unsafe_join``` property. AFAICT this "shadow" round is not documented anywhere outside the code implementing it.

CASSANDRA-13851 improved things by allowing other nodes that are not themselves booting to release a node from the shadow round and successfully boot. However, this still means a node that is booting must contact a seed or a peer that is not itself booting in order to start, making seed more crucial to booting than the docs imply. 

In particular, a full cluster bounce is not supported when there are no reachable seeds since the non-seed peers required to release a node from the shadow round will themselves be trapped in the shadow round.
Bug: Fix test: repair_tests.preview_repair_test.TestPreviewRepair
Status: Resolved
Priority: Normal
Resolution: Invalid
Created: 22/Jul/22 14:26
Resolved: 22/Jul/22 14:34

https://app.circleci.com/pipelines/github/driftx/cassandra/554/workflows/7d6bd03e-3388-4e12-b759-aece7b1bad2c/jobs/6688/tests#failed-test-0

{code}
Unexpected error found in node logs (see stdout for full details). Errors: [[node1] 'ERROR [Stream-Deserializer-/127.0.0.3:7000-31c78388] 2022-07-22 14:09:33,634 StreamSession.java:694 - [Stream #e94ccdaa-09c7-11ed-b1c3-e3af2c1ba287] Streaming error occurred on session with peer 127.0.0.3:7000\njava.lang.RuntimeException: null\n\tat org.apache.cassandra.streaming.StreamTransferTask.abort(StreamTransferTask.java:148)\n\tat org.apache.cassandra.streaming.StreamSession.completePreview(StreamSession.java:987)\n\tat org.apache.cassandra.streaming.StreamSession.prepareSynAck(StreamSession.java:770)\n\tat org.apache.cassandra.streaming.StreamSession.messageReceived(StreamSession.java:597)\n\tat org.apache.cassandra.streaming.StreamDeserializingTask.run(StreamDeserializingTask.java:76)\n\tat io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)\n\tat java.base/java.lang.Thread.run(Thread.java:829)', [node1] 'ERROR [Stream-Deserializer-/127.0.0.3:7000-204bfc69] 2022-07-22 14:09:36,092 StreamSession.java:694 - [Stream #eacd2c1a-09c7-11ed-b1c3-e3af2c1ba287] Streaming error occurred on session with peer 127.0.0.3:7000\njava.lang.RuntimeException: null\n\tat org.apache.cassandra.streaming.StreamTransferTask.abort(StreamTransferTask.java:148)\n\tat org.apache.cassandra.streaming.StreamSession.completePreview(StreamSession.java:987)\n\tat org.apache.cassandra.streaming.StreamSession.prepareSynAck(StreamSession.java:770)\n\tat org.apache.cassandra.streaming.StreamSession.messageReceived(StreamSession.java:597)\n\tat org.apache.cassandra.streaming.StreamDeserializingTask.run(StreamDeserializingTask.java:76)\n\tat 
{code}
Bug: WEBSITE - July 2022 blog "Apache Cassandra 4.1 Features: Pluggable Memtable Implementations"
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 19/Jul/22 23:02
Resolved: 22/Jul/22 05:19

This ticket is to capture the work associated with publishing the July 2022 blog "Apache Cassandra 4.1 Features: Pluggable Memtable Implementations"

If this blog cannot be published by the *July 21, 2022 publish date*, please contact me, suggest changes, or correct the date when possible in the pull request for the appropriate time that the blog will go live (on both the blog.adoc and the blog post's file).
Bug: Remove read_repair table option from <4.0 docs, and restore read_repair_chance docs
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 02/Jul/22 10:34
Resolved: 16/Jul/22 11:08

CASSANDRA-16763 added the read_repair docs to all versions. It should only have been added to 4.0 onwards.

The 3.11 docs is now missing the read_repair_chance information.

See doc/modules/cassandra/pages/cql/ddl.adoc and doc/modules/cassandra/pages/operating/read_repair.adoc
Bug: WEBSITE - July 2022 blog "Last Chance to Register: Schedule & Moderators Announced"
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 15/Jul/22 17:34
Resolved: 15/Jul/22 19:46

This ticket is to capture the work associated with publishing the July 2022 blog "Last Chance to Register: Schedule & Moderators Announced"

If this blog cannot be published by the *July 15, 2022 publish date*, please contact me, suggest changes, or correct the date when possible in the pull request for the appropriate time that the blog will go live (on both the blog.adoc and the blog post's file).
Bug: WEBSITE - July 2022 blog "Apache Cassandra Changelog #17"
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 11/Jul/22 20:26
Resolved: 13/Jul/22 15:58

This ticket is to capture the work associated with publishing the July 2022 blog "Apache Cassandra Changelog #17"

If this blog cannot be published by the *July 12, 2022 publish date*, please contact me, suggest changes, or correct the date when possible in the pull request for the appropriate time that the blog will go live (on both the blog.adoc and the blog post's file).
Bug: WEBSITE - July 2022 edit for blog "Talks & Sponsors Announced for Cassandra World Party 2022"
Status: Triage Needed
Priority: Normal
Created: 11/Jul/22 23:08

This ticket is to capture the work associated with editing the June 2022 blog "Talks & Sponsors Announced for Cassandra World Party 2022"

This edit should go up *ASAP*. Please contact me, suggest changes, or correct information in the pull request if necessary.
Bug: WEBSITE - July 2022 blog "Apache Cassandra 4.1: Configuration Standardization"
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 06/Jul/22 18:49
Resolved: 07/Jul/22 12:50

This ticket is to capture the work associated with publishing the June 2022 blog "Apache Cassandra 4.1: Configuration Standardization"

If this blog cannot be published by the *July 7, 2022 publish date*, please contact me, suggest changes, or correct the date when possible in the pull request for the appropriate time that the blog will go live (on both the blog.adoc and the blog post's file).
Bug: cassandra.service: main process exited, code=killed, status=11/SEGV
Status: Resolved
Priority: Normal
Resolution: Invalid
Created: 04/Jul/22 08:19
Resolved: 04/Jul/22 10:31

env:

apache-cassandra-4.0.0

jdk-11.0.12

ZGC

 

jvm:

-Xms31G
-Xmx31G

 

host:

16core 128G

 

message log:
{code:java}
Jul  4 13:57:10 iZ2zec1q29sosy4bdv893qZ systemd-logind: Removed session 277.
Jul  4 13:57:12 iZ2zec1q29sosy4bdv893qZ cassandra: INFO  [CompactionExecutor:4] 2022-07-04 13:57:12,074 CompactionTask.java:245 - Compacted (24af5250-fb5e-11ec-aa2a-6b96728ba428)
4 sstables to [/data/cassandra/data/data/spaceport/xm_coupon_code_realtime1-d77e7f10ebcc11ecae252faeea3c28c4/nb-6494-big,] to level=0.  27.414MiB to 27.412MiB (~99% of original) i
n 1,812ms.  Read Throughput = 15.127MiB/s, Write Throughput = 15.126MiB/s, Row Throughput = ~123,625/s.  32,718 total partitions merged to 32,689.  Partition merge counts were {1:
32663, 2:23, 3:3, }
Jul  4 13:57:12 iZ2zec1q29sosy4bdv893qZ cassandra: INFO  [NonPeriodicTasks:1] 2022-07-04 13:57:12,083 SSTable.java:111 - Deleting sstable: /data/cassandra/data/data/spaceport/xm_c
oupon_code_realtime1-d77e7f10ebcc11ecae252faeea3c28c4/nb-6490-big
Jul  4 13:57:12 iZ2zec1q29sosy4bdv893qZ cassandra: INFO  [NonPeriodicTasks:1] 2022-07-04 13:57:12,084 SSTable.java:111 - Deleting sstable: /data/cassandra/data/data/spaceport/xm_c
oupon_code_realtime1-d77e7f10ebcc11ecae252faeea3c28c4/nb-6493-big
Jul  4 13:57:12 iZ2zec1q29sosy4bdv893qZ cassandra: INFO  [NonPeriodicTasks:1] 2022-07-04 13:57:12,085 SSTable.java:111 - Deleting sstable: /data/cassandra/data/data/spaceport/xm_c
oupon_code_realtime1-d77e7f10ebcc11ecae252faeea3c28c4/nb-6491-big
Jul  4 13:57:12 iZ2zec1q29sosy4bdv893qZ cassandra: INFO  [NonPeriodicTasks:1] 2022-07-04 13:57:12,085 SSTable.java:111 - Deleting sstable: /data/cassandra/data/data/spaceport/xm_c
oupon_code_realtime1-d77e7f10ebcc11ecae252faeea3c28c4/nb-6492-big
Jul  4 14:00:01 iZ2zec1q29sosy4bdv893qZ systemd: Started Session 293 of user root.
Jul  4 14:01:01 iZ2zec1q29sosy4bdv893qZ systemd: Started Session 294 of user root.
Jul  4 14:01:59 iZ2zec1q29sosy4bdv893qZ systemd: cassandra.service: main process exited, code=killed, status=11/SEGV
Jul  4 14:02:00 iZ2zec1q29sosy4bdv893qZ systemd: Unit cassandra.service entered failed state.
Jul  4 14:02:00 iZ2zec1q29sosy4bdv893qZ systemd: cassandra.service failed.
Jul  4 14:02:05 iZ2zec1q29sosy4bdv893qZ systemd: cassandra.service holdoff time over, scheduling restart.
Jul  4 14:02:05 iZ2zec1q29sosy4bdv893qZ systemd: Stopped Cassandra Server Service.
Jul  4 14:02:05 iZ2zec1q29sosy4bdv893qZ systemd: Started Cassandra Server Service.
Jul  4 14:02:55 iZ2zec1q29sosy4bdv893qZ cassandra: CompileCommand: dontinline org/apache/cassandra/db/Columns$Serializer.deserializeLargeSubset(Lorg/apache/cassandra/io/util/DataI
nputPlus;Lorg/apache/cassandra/db/Columns;I)Lorg/apache/cassandra/db/Columns; {code}
Bug: Potential Refactoring Estimate
Status: Resolved
Priority: Normal
Resolution: Invalid
Created: 02/Jul/22 01:31
Resolved: 02/Jul/22 10:25

*Summary*

I have identified a few classes with refactoring potential along with its estimated time to refactor, specifically BatchlogManager.java. The estimated time is based on historical commits containing refactoring and the complexity of the involved classes. The class was refactored once on Jun 12, 2019 along with other classes in commit 310a48efcfdc0fb77fbd5fd6e734bf17667f617d. Given the duration of the last refactoring, could it be possible to improve this class further? I am probably not qualified and experienced enough to point out the exact code needs to be refactored, given my limited knowledge of the project and codebase.

 

*Urgency*

Low priority. For maintenance of code in the long run.

 

Hi,

I am currently doing some research on Estimating Time Taken for Software Refactoring. Cassandra is one of my case studies being a highly popular project. Would appreciate your kind feedback on the appropriateness of the estimated time to refactor. 

I am specifically looking at potential for refactoring, such as breaking functions that are too long into shorter functions, or to remove code duplication. Would you agree that there could be some modification to the code to make it better in the listed classes? And if so, is the estimated time appropriate to carry out the improvement? I will be grateful for any help you can provide.
 # BatchlogManager.java - 4 hours
 # ImmediateExecutor.java - 3 hours
 # DatabaseDescriptor.java - 3.5 hours

Thank you.
Bug: Move {{Schema.FORCE_LOAD_KEYSPACES}} and {{Schema.FORCE_LOAD_KEYSPACES_PROP}} to {{CassandraRelevantProps}}
Status: Resolved
Priority: Low
Resolution: Fixed
Created: 28/Jul/22 14:32
Resolved: 08/Nov/22 07:47

{{Schema.FORCE_LOAD_LOCAL_KEYSPACES_PROP}} and {{Schema.FORCE_LOAD_LOCAL_KEYSPACES}} should be moved to {{CassandraRelevantProps}} for two reasons. 

# Generally speaking, this is where these kinds of things live. 
# By having them in Schema, you can't actually use {{Schema.FORCE_LOAD_LOCAL_KEYSPACES_PROP}} without running all of the static initializers... and you want to use {{Schema.FORCE_LOAD_LOCAL_KEYSPACES_PROP}} to set the system property before the static initializer runs.
Bug: Change bin/cqlsh.py shebang to use PATH with env prefix
Status: Resolved
Priority: Low
Resolution: Fixed
Created: 18/Aug/22 03:26
Resolved: 18/Nov/22 13:40

For cqlsh.py this:

#!/usr/bin/env python

is preferable to the current hard coded /usr/bin/python3 which doesn't take into account the python interpreter preferences in the users PATH.  '{{{}env{}}}' is a system binary in {{/usr/bin}} that searches {{$PATH}} for strings containing the provided argument and returns the first instance it finds. In the above syntax, {{env}} will search for the first instance of {{python}} in {{$PATH}} and return it.

This is aligned with the recommendations in [https://peps.python.org/pep-0394/]

For example, on a MacOS Monterey 12.5.1 with both xcode python and brew installed python:

 
{code:java}
% /usr/bin/python3 --version
Python 3.8.9.   (xcode python version)
% /usr/bin/env python --version
Python 3.10.6.  (brew python version)
% python --version
Python 3.10.6.   (default)
{code}
Thus, /usr/bin/python3 doesn't run the expected default python version

Even the official Python tutorial uses the /usr/bin/env form of shebang: [https://docs.python.org/3/tutorial/interpreter.html]
Bug: Add metrics around storage usage and compression to enable easier comparison between existing and new compression algorithms
Status: Resolved
Priority: Low
Resolution: Fixed
Created: 14/Sep/22 19:09
Resolved: 19/Sep/22 16:05

To track gains in efficiency of compression and provide a common foundation for comparing different (and new!) compression algorithms we need to add a few new metrics:
 * Un-replicated logical storage load
 * Un-replicated, uncompressed logical storage load
 * Replicated but uncompressed storage load (like storage service load today, but showing compression)
Bug: All system properties and environment variables should be accessed via the new CassandraRelevantProperties and CassandraRelevantEnv classes
Status: Resolved
Priority: Low
Resolution: Fixed
Created: 03/Aug/22 20:30
Resolved: 11/May/23 05:41

Follow up ticket for CASSANDRA-15876 - 
"Always access system properties and environment variables via the new CassandraRelevantProperties and CassandraRelevantEnv classes"
As part of that ticket we moved to the two new classes only properties/variables that were currently listed in System Properties Virtual Table.
We have to move to those classes the rest of the properties around the code and start using those classes to access all of them. 

+Additional information for newcomers:+

You might want to start by getting acquainted with CassandraRelevantProperties and CassandraRelevantEnv classes. Also, you might want to check what changes were done and how the first batch was transferred to this new framework as part of  [CASSANDRA-15876|https://github.com/apache/cassandra/commit/7694c1d191531ac152db55e83bc0db6864a5441e]

We are interested into the properties accessed currently through getProperties around the code.

As part of CASSANDRA-15876 relevant unit tests were added (CassandraRelevantPropertiesTest). To verify the new patch we need to ensure that all tests Cassandra pass and also to think about potential update of the mentioned test class.
Bug: Better Behavior for GCInspector with Low Pause Time GCs
Status: Open
Priority: Low
Created: 12/Jul/22 22:56

Low pause time GCs like Shenandoah tend to be very spammy when it comes to running Cassandra with the default configuration. This is because GCInspector seems to detect that Shenandoah cycles are equivalent to GC pauses and because these cycles tend to be relatively long (in the order of 2-3 seconds in my experience) GCInspector constantly throws warnings. However, these cycle times are normal and are not an indicator of resource contention or heap pressure as the actual pause times are very short.

It would be great if Cassandra could be modified such that GCInspector had different behavior if a low pause time collector was detected as being in use (such as perhaps disabling the warning altogether).

Note that I used Shenandoah here for my example but ZGC is presumed to have similar behavior.
Bug: Switch to using @Nullable for all Config class properties which can be nullable
Status: Open
Priority: Low
Created: 29/Jul/22 00:11

Currently we allow [here|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/config/YamlConfigurationLoader.java#L369] null value for those properties that have null default value in Config.

We added exception for two properties as part of this PR - [https://github.com/apache/cassandra/pull/1758#discussion_r932618899]

As discuessed in the PR, we would  like to explore the opportunity to switch nullable properties to using the @Nullable annotation no matter whether they are or they are not having null value in Config.

We need to ensure extensive testing for this switch plus documenting it.
Bug: Test Failure: dtest-upgrade.upgrade_tests.upgrade_through_versions_test.TestUpgrade_indev_4_1_x_To_indev_trunk.test_parallel_upgrade 
Status: Open
Priority: Low
Created: 14/Sep/22 15:56

Link to failure: https://ci-cassandra.apache.org/job/Cassandra-4.1/162/testReport/dtest-upgrade.upgrade_tests.upgrade_through_versions_test/TestUpgrade_indev_4_1_x_To_indev_trunk/test_parallel_upgrade/

Error Message
Failed: Timeout >900.0s

Stack Trace
{code}
                else:
                    # wait for the situation to clarify, either stop or just a pause in log production
>                   time.sleep(1)
E                   Failed: Timeout >900.0s
{code}
Bug: Update Python test framework from nose to pytest in CCM
Status: Resolved
Priority: Low
Resolution: Fixed
Created: 25/Aug/22 12:55
Resolved: 24/Feb/23 18:10

According to the homepage of nose at [https://nose.readthedocs.io/en/latest/]
h1. _Note to Users_

_Nose has been in maintenance mode for the past several years and will likely cease without a new person/team to take over maintainership. New projects should consider using [Nose2|https://github.com/nose-devs/nose2], [py.test|http://pytest.org/], or just plain unittest/unittest2._

Another migration to pytest was already done in CASSANDRA-17293 and it seems not hard but at the same time valuable.

CC [~bschoeni] 

[CCM|https://github.com/riptano/ccm] repo
Bug: Further updates needed post CASSANDRA-12883 - removal of non-JavaScript scripted UDFs
Status: Open
Priority: Low
Created: 13/Sep/22 00:18

Non-JavaScript scripted UDFs were removed as part of CASSANDRA-12883 but several updates were missed which makes it confusing for users. To name a few I found so far:
 * cassandra.yaml  -  Enable this option to be able to use UDFs with "language javascript" or any custom JSR-223 provider.
 * docs [functions page |https://cassandra.apache.org/doc/4.1/cassandra/cql/functions.html]  "Support for other JSR 223 compliant scripting languages, such as Python, Ruby, and Scala, is possible by adding a JAR to the classpath."

I suspect we also need to update bin/cassandra.in.sh which still tries to collect all JSR223 engines' jars in trunk
Bug: Fix issues with index_summary_resize_interval and index_summary_capacity
Status: Resolved
Priority: Low
Resolution: Fixed
Created: 06/Jul/22 14:59
Resolved: 22/Jul/22 13:55

There are a few problems:

4.0+:
 * the virtual table displays only the cassandra.yaml values for both properties, all changes after startup are not updated

4.1+:
 *  Breaking compatibility - -1 was considered disabled, this should be considered as null now for the new config. The converter should be updated. There is a test for the -1, disable but it didn't caught the issue because of the previous issue mentioned (the disconnect between jmx and the actual property in Config class)
Bug: Consider to not warn about deprecated properties in logs when the value is not deprecated
Status: Resolved
Priority: Low
Resolution: Fixed
Created: 18/Sep/22 07:17
Resolved: 19/Sep/22 22:38

When there is an initialisation of database descriptor for tools, for example via "Util.initDatabaseDescriptor()", it will eventually buble up to "YamlConfigurationLoader.check" where this is logged:
{code}
if (!deprecationWarnings.isEmpty())
logger.warn("{} parameters have been deprecated. They have new names and/or value format; For more information, please refer to NEWS.txt", deprecationWarnings);
{code}

For example, I saw this log:

{code}
WARN  09:07:42,486 [key_cache_save_period, counter_cache_save_period, row_cache_save_period] parameters have been deprecated. They have new names and/or value format; For more information, please refer to NEWS.txt
{code}

The "problems" I see are two:
1) it pollutes the console for tool commands, when a tool needs to initialise DD, at the very beginning of the output.
2) When you look closely, for example at key_cache_save_period, by default, in cassandra.yaml, it has value "4h". My question is: why is it necessary to mark that as deprecated when the value is already in new format? In other words, I would log that warning only in case that the expected value of a property is not in the new format. But when it already is, why do we need to inform a user about that?

I think it would require to take some extra care for cases like these in YamlConfigurationLoader.getProperty to not add deprecated properties if their value is already new.
Bug: History Builder API 2.0
Status: Resolved
Priority: Urgent
Resolution: Fixed
Created: 29/Nov/23 16:44
Resolved: 07/Dec/23 12:43

Harry history Builder 2.0

      * New History Builder API
      * Add an ability to track LTS visiteb by partition in visited_lts static column
      * Add a model checker that checks against a different Cluster instance (for example, flush vs no flush, local vs nonlocal, etc)
      * Add an ability to issue LTSs out-of-order