av9ash/GitBugs huggingface dataset:
Bug: add ifesdjeen's gpg key to project's KEYS file
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 21/Mar/20 11:50
Resolved: 26/Mar/20 18:16

The patch adds my gpg public key to the project's KEYS file found at https://dist.apache.org/repos/dist/release/cassandra/KEYS

My gpg public key here has the fingerprint 
 9E66CEC6106D578D0B1EB9BFF1000962B7F6840C

References:
 - https://www.apache.org/dev/release-signing#keys-policy
 - http://www.apache.org/legal/release-policy.html
Bug: Support Logback and log4j2
Status: Open
Priority: Normal
Created: 27/Feb/20 21:34

Right now we only support Logback, CCM expects this as well; it is desirable to also support log4j2.

Right now, if someone wishes to use log4j2 they have to do the following

1) Compile with Logback
2) delete logback jars
3) add log4j2 jars
4) disable logging in CCM

This should be simpler and should just be based off the operator (if Logback is better for you, use it, if log4j2 is then use it).

The main point where we depend on Logback is org.apache.cassandra.utils.logging.LogbackLoggingSupport and this is only enabled if org.apache.cassandra.utils.logging.LoggingSupportFactory sees “logback” in the class name; else everything is disabled (which is why the above steps work). This logic adds some nice integration so this should not be lost and should also be supported in log4j2.

Lastly, given the implementation of how slf4j picks the binding (ServiceLoader which is classpath order), we should make sure its clear how to properly switch between the two; ideally, if the operator some how selects both, the behavior should be deterministic (slf4j is not))
Bug: Fix flaky tests org.apache.cassandra.service.MoveTest testStateJumpToNormal and testMoveWithPendingRangesNetworkStrategyRackAwareThirtyNodes
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 05/Feb/20 19:00
Resolved: 10/Apr/20 16:34

testStateJumpToNormal failure was on java 11
{code}
java.lang.NullPointerException
	at org.apache.cassandra.gms.Gossiper.getHostId(Gossiper.java:1028)
	at org.apache.cassandra.gms.Gossiper.getHostId(Gossiper.java:1023)
	at org.apache.cassandra.service.StorageService.handleStateNormal(StorageService.java:2513)
	at org.apache.cassandra.service.StorageService.onChange(StorageService.java:2055)
	at org.apache.cassandra.Util.createInitialRing(Util.java:225)
	at org.apache.cassandra.service.MoveTest.testStateJumpToNormal(MoveTest.java:935)
	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}

testMoveWithPendingRangesNetworkStrategyRackAwareThirtyNodes failure was on java 8
{code}
java.lang.NullPointerException
	at org.apache.cassandra.service.StorageService.updatePeerInfo(StorageService.java:2174)
	at org.apache.cassandra.service.StorageService.handleStateNormal(StorageService.java:2511)
	at org.apache.cassandra.service.StorageService.onChange(StorageService.java:2055)
	at org.apache.cassandra.Util.createInitialRing(Util.java:225)
	at org.apache.cassandra.service.MoveTest.testMoveWithPendingRangesNetworkStrategyRackAwareThirtyNodes(MoveTest.java:199)
{code}
Bug: Fix flakey test - org.apache.cassandra.index.sasi.SASIIndexTest testConcurrentMemtableReadsAndWrites
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 24/Jan/20 23:38
Resolved: 19/Mar/20 19:53

{code}
junit.framework.AssertionFailedError
  at org.apache.cassandra.index.sasi.utils.RangeIterator.<init>(RangeIterator.java:46)
  at org.apache.cassandra.index.sasi.memory.KeyRangeIterator.<init>(KeyRangeIterator.java:42)
  at org.apache.cassandra.index.sasi.memory.TrieMemIndex$ConcurrentTrie.search(TrieMemIndex.java:150)
  at org.apache.cassandra.index.sasi.memory.TrieMemIndex.search(TrieMemIndex.java:102)
  at org.apache.cassandra.index.sasi.memory.IndexMemtable.search(IndexMemtable.java:70)
  at org.apache.cassandra.index.sasi.conf.ColumnIndex.searchMemtable(ColumnIndex.java:138)
  at org.apache.cassandra.index.sasi.TermIterator.build(TermIterator.java:91)
  at org.apache.cassandra.index.sasi.plan.QueryController.getIndexes(QueryController.java:145)
  at org.apache.cassandra.index.sasi.plan.Operation$Builder.complete(Operation.java:434)
  at org.apache.cassandra.index.sasi.plan.QueryPlan.analyze(QueryPlan.java:57)
  at org.apache.cassandra.index.sasi.plan.QueryPlan.execute(QueryPlan.java:68)
  at org.apache.cassandra.index.sasi.SASIIndex.lambda$searcherFor$2(SASIIndex.java:301)
  at org.apache.cassandra.db.ReadCommand.executeLocally(ReadCommand.java:455)
  at org.apache.cassandra.index.sasi.SASIIndexTest.getIndexed(SASIIndexTest.java:2576)
  at org.apache.cassandra.index.sasi.SASIIndexTest.getPaged(SASIIndexTest.java:2537)
  at org.apache.cassandra.index.sasi.SASIIndexTest.testConcurrentMemtableReadsAndWrites(SASIIndexTest.java:1108)
  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: When running CQLSH with STDIN input, exit with error status code if script fails
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 06/Mar/20 07:46
Resolved: 18/Apr/20 05:30

Assuming CASSANDRA-6344 is in place for years and considering that scripts submitted with the `-e` option behave in a similar fashion, it is very surprising that scripts submitted to STDIN (i.e. piped in) always exit with a zero code, regardless of errors. I believe this should be fixed.
Bug: Extract in-jvm API and tests out of Cassandra and into a separate repository
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 31/Jan/20 12:59
Resolved: 27/Mar/20 18:26

Extract in-jvm DTest _API_ and tests into a separate repository that is shared between Cassandra branches. Tests themselves should be buildable using just API, which is not  the case now, since cluster creation relies on impl package, since we do not have factories / constructors in API.

Main goals we’re trying to achieve:
1. We should be able to fail a build on API incompatibility between versions 
2. Make it as easy as possible to detect break APIs between versions. 
3. Make development of _tests_ based on in-jvm framework simpler
4. Reduce surface area of impact when making modifications to tests 

Potentially, we’d also like to use a plugin to detect API incompatibilities between in-jvm DTest API and in-branch implementations, and start running tests using shared in-jvm test repository with each existing implementation in the branch. This entails both running tests for all branches whenever there’s a change in tests jar and running tests for a specific branch whenever the branch has changed.
Bug: Support additional Jar url scheme
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 08/Jan/20 23:03
Resolved: 12/Feb/20 19:36

This code in ThreadAwareSecurityManager causes issues for embedded cassandra launched from a one-jar or uno-jar.

{code:java}

                switch (codesource.getLocation().getProtocol())
                {
                    case "file":
                        // All JARs and class files reside on the file system - we can safely
                        // assume that these classes are "good".
                        return true;
                }

{code}

Attaching patch to support protocol of 'jar' as well. AFAICT this won't introduce any added risk for UDF's discussed in CASSANDRA-9402 since a jar (or one/uno jar) must also be on the filesystem. 

New code would be (in 2 places):
{code:java}

                switch (codesource.getLocation().getProtocol())
                {
                    case "jar":
                    case "file":
                        // All JARs and class files reside on the file system - we can safely
                        // assume that these classes are "good".
                        return true;
                }

{code}
Bug: 4.0 quality testing: Test Frameworks, Tooling, Infra / Automation
Status: Resolved
Priority: Normal
Resolution: Done
Created: 18/Feb/20 18:33
Resolved: 20/Mar/21 17:29

Reference [doc from NGCC|https://docs.google.com/document/d/1uhUOp7wpE9ZXNDgxoCZHejHt5SO4Qw1dArZqqsJccyQ/edit#] for context.

*Shepherd: Jordan West*

This area refers to contributions to test frameworks/tooling (e.g., dtests, QuickTheories, CASSANDRA-14821), and automation enabling those tools to be applied at scale (e.g., replay testing via Spark-based replay of captured FQL logs).
Bug: 4.0 quality testing: Cluster Setup and Maintenance
Status: Resolved
Priority: Normal
Resolution: Resolved
Created: 18/Feb/20 18:34
Resolved: 14/Jan/21 01:22

We want 4.0 to be easy for users to setup out of the box and just work. This means having low friction when users download the Cassandra package and start running it. For example, users should be able to easily configure and start new 4.0 clusters and have tokens distributed evenly. Another example is packaging, it should be easy to install Cassandra on all supported platforms (e.g. packaging) and have Cassandra use standard platform integrations.
Bug: 4.0 quality testing: Tooling - External Ecosystem
Status: Resolved
Priority: Normal
Resolution: Done
Created: 18/Feb/20 18:32
Resolved: 19/Mar/21 11:40

Reference [doc from NGCC|https://docs.google.com/document/d/1uhUOp7wpE9ZXNDgxoCZHejHt5SO4Qw1dArZqqsJccyQ/edit#] for context.

*Shepherd: Benjamin Lerer*

Many users of Apache Cassandra employ open source tooling to automate Cassandra configuration, runtime management, and repair scheduling. Prior to release, we need to confirm that popular third-party tools function properly. 

Current list of tools:
|| Name || Status || Contact ||
| [Priam|http://netflix.github.io/Priam/] |{color:#00875A} *DONE WITH ALPHA*{color} (need to be tested with beta) | [~sumanth.pasupuleti]| 
| [sstabletools|https://github.com/instaclustr/cassandra-sstable-tools] | {color:#00875A}*DONE*{color} | [~stefan.miklosovic]| 
| [Instaclustr Cassandra operator|https://github.com/instaclustr/cassandra-operator]|  {color:#00875A}*DONE*{color} | [~stefan.miklosovic]|
| [Instaclustr Esop | https://github.com/instaclustr/instaclustr-esop]|{color:#00875A}*DONE*{color} | [~stefan.miklosovic]|
| [Instaclustr Icarus | https://github.com/instaclustr/instaclustr-icarus]|{color:#00875A}*DONE*{color} | [~stefan.miklosovic]|
| [Cassandra SSTable generator | https://github.com/instaclustr/cassandra-sstable-generator]|{color:#00875A}*DONE*{color}| [~stefan.miklosovic]|
| [Cassandra TTL Remover | https://github.com/instaclustr/TTLRemover] | {color:#00875A}*DONE*{color} |  [~stefan.miklosovic]|
| [Cassandra Everywhere Strategy | https://github.com/instaclustr/cassandra-everywhere-strategy] | {color:#00875A}*DONE*{color} | [~stefan.miklosovic]|
| [Cassandra LDAP Authenticator | https://github.com/instaclustr/cassandra-ldap] | {color:#00875A}*DONE*{color} | [~stefan.miklosovic]|
| [Instaclustr Minotaur | https://github.com/instaclustr/instaclustr-minotaur] | {color:#00875A}*DONE*{color} | [~stefan.miklosovic]|
| [Reaper|http://cassandra-reaper.io/]| {color:#00875A}*AUTOMATIC*{color} | [~adejanovski]|
| [Medusa|https://github.com/thelastpickle/cassandra-medusa]|  {color:#00875A}*DONE*{color}| [~adejanovski]|
| [spark-cassandra-connector|https://github.com/datastax/spark-cassandra-connector]| {color:#00875A}*DONE*{color}| [~jtgrabowski]|
| [cass operator|https://github.com/datastax/cass-operator]| {color:#00875A}*DONE*{color}| [~jimdickinson]|
| [metric collector|https://github.com/datastax/metric-collector-for-apache-cassandra]| {color:#00875A}*DONE*{color}| [~tjake]|
| [managment API|https://github.com/datastax/management-api-for-apache-cassandra]| {color:#00875A}*DONE*{color}| [~tjake]|  

Columns descriptions:
* *Name*: Name and link to the tool official page
* *Status*: {{NOT STARTED}}, {{IN PROGRESS}}, {{BLOCKED}} if you hit any issue and have to wait for it to be solved, {{DONE}}, {{AUTOMATIC}} if testing 4.0 is part of your CI process.
* *Contact*: The person acting as the contact point for that tool.
Bug: 4.0 quality testing: Distributed Read/Write Path: Coordination, Replication, and Read Repair
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 18/Feb/20 18:25
Resolved: 11/Jun/21 15:08

Reference [doc from NGCC|https://docs.google.com/document/d/1uhUOp7wpE9ZXNDgxoCZHejHt5SO4Qw1dArZqqsJccyQ/edit#] for context.

*Shepherd: {color:#de350b}None{color}*

Testing in this area focuses on non-node-local aspects of the read-write path: coordination, replication, read repair, etc.
Bug: DESCRIBE KEYSPACE does not properly quote table names
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 26/Mar/20 06:13
Resolved: 13/Jul/21 12:41

How to reproduce (3.11.6) - cqlsh:

{code}
CREATE KEYSPACE test1 WITH replication = \{'class': 'SimpleStrategy', 'replication_factor': '1'} AND durable_writes = true;
CREATE TABLE test1."default" (id text PRIMARY KEY, data text, etag text);
DESCRIBE KEYSPACE test1;
{code}

Output will be:

{code}
CREATE TABLE test1.default (
 id text PRIMARY KEY,
 data text,
 etag text
) WITH [..]
{code}

Output should be:

{code}
CREATE TABLE test1."default" (
 id text PRIMARY KEY,
 data text,
 etag text
) WITH [..]
{code}

 If you try to run {{CREATE TABLE test1.default [..]}} you will get an error 

SyntaxException: line 1:19 no viable alternative at input 'default' (CREATE TABLE test1.[default]...)

Oskar Liljeblad
Bug: LeveledCompactionStrategy compact last level throw an ArrayIndexOutOfBoundsException
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 27/Mar/20 13:58
Resolved: 31/May/21 18:24

Cassandra will throw an ArrayIndexOutOfBoundsException when compact last level.

My test is as follows：
 # Create a table with LeveledCompactionStrategy and its params are 'enabled': 'true', 'fanout_size': '2', 'max_threshold': '32', 'min_threshold': '4', 'sstable_size_in_mb': '2'（fanout_size and sstable_size_in_mb are too small just to make it easier to reproduce the problem）;
 # Insert data into the table by stress;
 # Cassandra throw an ArrayIndexOutOfBoundsException when compact level9 sstables(this level score bigger than 1.001)

ERROR [CompactionExecutor:4] 2020-03-28 08:59:00,990 CassandraDaemon.java:442 - Exception in thread Thread[CompactionExecutor:4,1,main]
 java.lang.ArrayIndexOutOfBoundsException: 9
 at org.apache.cassandra.db.compaction.LeveledManifest.getLevel(LeveledManifest.java:814)
 at org.apache.cassandra.db.compaction.LeveledManifest.getCandidatesFor(LeveledManifest.java:746)
 at org.apache.cassandra.db.compaction.LeveledManifest.getCompactionCandidates(LeveledManifest.java:398)
 at org.apache.cassandra.db.compaction.LeveledCompactionStrategy.getNextBackgroundTask(LeveledCompactionStrategy.java:131)
 at org.apache.cassandra.db.compaction.CompactionStrategyHolder.lambda$getBackgroundTaskSuppliers$0(CompactionStrategyHolder.java:109)
 at org.apache.cassandra.db.compaction.AbstractStrategyHolder$TaskSupplier.getTask(AbstractStrategyHolder.java:66)
 at org.apache.cassandra.db.compaction.CompactionStrategyManager.getNextBackgroundTask(CompactionStrategyManager.java:214)
 at org.apache.cassandra.db.compaction.CompactionManager$BackgroundCompactionCandidate.run(CompactionManager.java:289)
 at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
 at java.util.concurrent.FutureTask.run$$$capture(FutureTask.java:266)
 at java.util.concurrent.FutureTask.run(FutureTask.java)
 at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
 at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
 at io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
 at java.lang.Thread.run(Thread.java:748)

I tested it on cassandra version 3.11.3 & 4.0-alpha3. The exception all happened.

once it triggers, level1- leveln compaction no longer works, level0 is still valid
Bug: 4.0 quality testing: Repair
Status: In Progress
Priority: Normal
Created: 18/Feb/20 18:26

Reference [doc from NGCC|https://docs.google.com/document/d/1uhUOp7wpE9ZXNDgxoCZHejHt5SO4Qw1dArZqqsJccyQ/edit#] for context.

*Shepherd: Alexander Dejanovski*

We aim for 4.0 to have the first fully functioning incremental repair solution (CASSANDRA-9143)! Furthermore we aim to verify that all types of repair: (full range, sub range, incremental) function as expected as well as ensuring community tools such as Reaper work. CASSANDRA-3200 adds an experimental option to reduce the amount of data streamed during repair, we should write more tests and see how it works with big nodes.
Bug: Topology events are not sent to clients if the nodes use the same network interface
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 30/Mar/20 18:26
Resolved: 22/Jun/20 14:19

*This bug only happens when the cassandra nodes are configured to use a single network interface (ip) but different ports.  See CASSANDRA-7544.*

Issue: The topology events aren't sent to clients. The problem is that the port is not taken into account when determining if we send it or not:
https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/transport/Server.java#L624

To reproduce:
{code}
# I think the cassandra-test branch is required to get the -S option (USE_SINGLE_INTERFACE)
ccm create -n4 local40 -v 4.0-alpha2 -S
{code}
 
Then run this small python driver script:
{code}
import time
from cassandra.cluster import Cluster

cluster = Cluster()
session = cluster.connect()

while True:
    print(cluster.metadata.all_hosts())
    print([h.is_up for h in cluster.metadata.all_hosts()])
    time.sleep(5)
{code}

Then decommission a node:
{code}
ccm node2 nodetool disablebinary
ccm node2 nodetool decommission
{code}
 
You should see that the node is never removed from the client cluster metadata and the reconnector started.
Bug: Script to autogenerate cassandra.yaml
Status: In Progress
Priority: Normal
Created: 11/Mar/20 17:15

It would be useful to have a script that can ask the user a few questions and generate a recommended cassandra.yaml based on their answers. This will help solve issues like selecting num_tokens. It can also be integrated into OS specific packaging tools such as debconf[1]. Rather than just documenting on the website, it is best to provide a simple script to auto-generate configuration based on common use-cases.

[1] https://wiki.debian.org/debconf
Bug: digest may not match when single partition named queries skip older sstables
Status: Resolved
Priority: Normal
Resolution: Duplicate
Created: 13/Mar/20 08:29
Resolved: 04/May/21 13:28

Name queries (aka. single partition query with full clustering keys) query sstables sequentially in recency order, in the hope that most recent sstables will contain most recent data, so that they can avoid reading older sstables in {{SinglePartitionReadCommand#reduceFilter}}.

Unfortunately, this optimization may cause digest mismatch if older sstables contain range tombstone or row deletion with lower timestamp. [Test Code|https://github.com/jasonstack/cassandra/commit/3dfa29bb34bc237ab2b68f849906c09569c5cc94]
{code:java}
Table with (pk, ck1, ck2)

Node1:
* delete row (pk=1, ck1=1) with ts=10
* insert row (pk=1, ck1=1, ck2=1) with ts=11

Node2:
* delete row (pk=1, ck1=1) with ts=10
* flush into sstable1
* insert row (pk=1, ck1=1, ck2=1) with ts=11
* flush into sstable2

Query with pk=1 and ck1=1 and ck2=1
* node1 returns: RT open marker, row, RT close marker
* node2 returns: row  (because sstable1 is skipped)

Note: similar mismatch can happen with row deletion as well.
{code}
In the above example: Is it safe to ignore RT or row deletion if row liveness has higher timestamp for named queries in node1?
Bug: 4.0 quality testing: Compaction
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 18/Feb/20 18:27
Resolved: 15/Mar/21 17:51

Reference [doc from NGCC|https://docs.google.com/document/d/1uhUOp7wpE9ZXNDgxoCZHejHt5SO4Qw1dArZqqsJccyQ/edit#] for context.

*Shepherd: Marcus Eriksson*

Alongside the local and distributed read/write paths, we'll also want to validate compaction. CASSANDRA-6696 introduced substantial changes/improvements that require testing (esp. JBOD).
Bug: 4.0 quality testing: Platforms and Runtimes
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 18/Feb/20 18:34
Resolved: 13/Jan/21 08:58

Reference [doc from NGCC|https://docs.google.com/document/d/1uhUOp7wpE9ZXNDgxoCZHejHt5SO4Qw1dArZqqsJccyQ/edit#] for context.

*Shepherd: {color:#ff0000}NONE{color}*

CASSANDRA-9608 introduces support for Java 11. We'll want to verify that Cassandra under Java 11 meets expectations of stability.
Bug: 4.0 quality testing: Local Read/Write Path: Other Areas
Status: Open
Priority: Normal
Created: 30/Jan/20 21:09

Reference [doc from NGCC|https://docs.google.com/document/d/1uhUOp7wpE9ZXNDgxoCZHejHt5SO4Qw1dArZqqsJccyQ/edit#] for context.

*Shepherd: Aleksey Yeschenko*

Testing in this area refers to the local read/write path (StorageProxy, ColumnFamilyStore, Memtable, SSTable reading/writing, etc). We are still finding numerous bugs and issues with the 3.0 storage engine rewrite (CASSANDRA-8099). For 4.0 we want to ensure that we thoroughly cover the local read/write path with techniques such as property-based testing, fuzzing ([example|http://cassandra.apache.org/blog/2018/10/17/finding_bugs_with_property_based_testing.html]), and a source audit.
Bug: 4.0 quality testing: Local Read/Write Path: Upgrade and Diff Test
Status: Resolved
Priority: Normal
Resolution: Done
Created: 30/Jan/20 21:07
Resolved: 19/Mar/21 11:25

Reference [doc from NGCC|https://docs.google.com/document/d/1uhUOp7wpE9ZXNDgxoCZHejHt5SO4Qw1dArZqqsJccyQ/edit#] for context.

Execution of upgrade and diff tests via cassandra-diff have proven to be one of the most effective approaches toward identifying issues with the local read/write path. These include instances of data loss, data corruption, data resurrection, incorrect responses to queries, incomplete responses, and others. Upgrade and diff tests can be executed concurrent with fault injection (such as host or network failure); as well as during mixed-version scenarios (such as upgrading half of the instances in a cluster, and running upgradesstables on only half of the upgraded instances).

Upgrade and diff tests are expected to continue through the release cycle, and are a great way for contributors to gain confidence in the correctness of the database under their own workloads.