av9ash/GitBugs huggingface dataset:
Bug: WEBSITE - 4.0 GA announcement + July 2021 updates
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 14/Jul/21 00:42
Resolved: 31/Jul/21 15:58

HTML updates to be made to the website that include:
* Added blog - Apache Cassandra 4.0 is Here, approved by PMC on private mailing list
* Added card for the new blog to blog index
* Replaced homepage World Party promo with 4.0 announcement and blog link
* Updated homepage community spotlight
* Added Backblaze logo to homepage logos list
* Added missing <p> tag in Apache Cassandra Changelog 8 June 2021 blog and Cassandra and Kubernetes SIG Update 2 blog
* Added <hr> tag and link back to blog index on World Party, Speakers Announced for April 28 Cassandra 4.0 World Party, and Join Cassandra GSoC 2021 blogs
* Added cassandra-case-studies directory with the Backblaze case study
* Added Backblaze to case studies index
* Added Backblaze logo to img/companies directory
* Added updates to Ecosystem webpage based on requests received to email sent to user list/dev lists including:

    - Apache Drill to Connectors
    - Digitalis to Professional Support
    - Nifi to Tools
    - Netflix Data Explorer to Tools
    - Changed Stratio to Cassandra Lucene Index per request on ML
Bug: Fix dtest-novnode.materialized_views_test.TestMaterializedViews.test_drop_with_stopped_build
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 16/Sep/21 16:02
Resolved: 23/Feb/22 08:25

Failed in Jenkins 4.0:

[https://jenkins-cm4.apache.org/job/Cassandra-4.0/213/testReport/junit/dtest-novnode.materialized_views_test/TestMaterializedViews/test_drop_with_stopped_build/]

 

 
{code:java}
dtest-novnode.materialized_views_test.TestMaterializedViews.test_drop_with_stopped_build (from Cassandra dtests)

Failing for the past 1 build (Since #213 ) Took 1 min 33 sec.    Failed 1 times in the last 30 runs. Flakiness: 3%, Stability: 96% Error Message
AssertionError: Expected [[5000]] from SELECT COUNT(*) FROM t_by_v, but got [[4991]]

{code}
Bug: Reduce the amount of logging on "expected" repair exceptions
Status: Resolved
Priority: Normal
Resolution: Duplicate
Created: 19/Aug/21 17:26
Resolved: 24/Aug/21 20:59

Many of the repair errors we throw in the logs are redundant. For example, if one node has an unreadable sstable, we should log that at ERROR, but then the failing repairs due to that unreadable sstable should be at WARN, making it easier to find and debug the actual problem.
Bug: Documentation links broken, indexed by Google
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 29/Jul/21 21:34
Resolved: 04/Aug/21 19:39

Internal documentation links like [https://cassandra.apache.org/doc/latest/operating/compaction/index.html] are now returning 404s. These links originate from within documentation (referenced from [https://cassandra.apache.org/doc/latest/)] and are indexed by Google (first result for "apache cassandra compaction", for example).

These links were working correctly as recently as late 2020: https://web.archive.org/web/20201020194414/https://cassandra.apache.org/doc/latest/operating/compaction/index.html
Bug: WEBSITE - August 2021 updates
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 06/Aug/21 06:21
Resolved: 18/Aug/21 21:06

Updates to be made to the website that include:

* add blog post: Apache-Cassandra-4.0-Overview.adoc to pages/blog
* added Apache Cassandra 4.0 Overview card to blog page
* If unable to post on August 6, 2021, the above will need an edit to publish dates
* added case study for Stibo Systems to case studies page
* add 4.0-overview-1.png and 4.0-overview-2.png to images/blog
* add stibo-systems.png to images/companies
* instagram.*png* to replace instagram.*jpg* in images/companies
* corrected logo for Instagram and added Stibo Systems logo to home page index
* corrected logo for Instagram and added Stibo Systems logo to case studies page
Bug: DOC - Broken link to contribution on community page
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 10/Aug/21 10:41
Resolved: 19/Aug/21 19:59

Becoming a contributor in [How to Contribute|https://cassandra.apache.org/_/community.html#how-to-contribute] section contains link under {{contribute to Cassandra}}, which leads to cannot find the server and the link is [https://doc/latest/development/index.html] 

 

The issue is probably due to extra / in
<a href="//doc/latest/development/index.html"
Bug: WEBSITE - Autogenerate blog index
Status: Triage Needed
Priority: Normal
Created: 21/Sep/21 14:25

h1. Summary

Enhance the website generation so that the blog index page is automatically populated based on the contents of the blog folder.
h1. Details

When an author needs to add a blog post, they need to update the blog index page as well as add the new post. This can be tedious for new contributors and in general is error prone.

We need to add the ability to autogenerate the blog index page when the website is rendered.

This might be possible through the use of a JS function that is registered with Antora and called when it runs. The JS function could generate the blog index page from the contents of the blog directory and information in each of the blogs.
Bug: WEBSITE - October 2021 blog post for Apache Cassandra Changelog #10
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 30/Sep/21 22:54
Resolved: 15/Jan/22 16:21

This ticket is to capture the work associated with publishing the October 2021 blog post for the Apache Cassandra Changelog #10.

We can close this once the blog post has gone live on the website.
Bug: Flaky test: repair_tests/repair_test.py::TestRepair::test_local_dc_repair
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 16/Sep/21 16:03
Resolved: 11/Jan/22 18:41

Sometimes we get “ID mismatch while trying to reprepare” after node restart on write workload in dtests, which we can avoid by using fully qualified cf names.
Bug: Shutdown hook is removed after non-fatal OutOfMemoryError
Status: Triage Needed
Priority: Normal
Created: 09/Sep/21 21:25

On CASSANDRA-7507 the drain shutdown hook is removed when the process hits an OutOfMemoryError, to avoid trying to do a clean shutdown when the node runs out of heap space.

On CASSANDRA-13006 cassandra started relying on JVM flags (ExitOnOutOfMemoryError and CrashOnOutOfMemoryError) to stop the node when hitting and OutOfMemoryError.

However, there are non-fatal {{OutOfMemoryErrors}} such as {{OutOfMemory: unable to create new native thread}} or {{OutOfMemory: map failed}} which [do not cause the process to crash even with the ExitOnOutOfMemoryError or CrashOnOutOfMemoryError flags|https://bugs.openjdk.java.net/browse/JDK-8155004].

Since the shutdown hook is removed after non-fatal OutOfMemory errors, it's no longer possible to do a clean shutdown (via {{SIGTERM kill}} or {{nodetool stopdaemon}}).

I believe the intent of CASSANDRA-7507 was to remove the shutdown hook only on fatal OutOfMemoryErrors (such as Heap Space Exhausted), those causing the node to crash. If a node is kept running after an OutOfMemoryError, this should not prevent the node from being cleanly shutdown afterwards.

We should either make the JVM exit on any OutOfMemory error, or remove the drain shutdown hook only on fatal OutOfMemoryErrors, those that will cause the JVM to crash straight away.
Bug: testsome fails in the CircleCI multiplexer because the class JStackJUnitTask can't be found
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 12/Aug/21 21:49
Resolved: 16/Aug/21 17:03

As [~adelapena] explained on [CASSANDRA-16827|https://issues.apache.org/jira/browse/CASSANDRA-16827?focusedCommentId=17398060&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17398060], the problem might be in the flag _-Dno-build-test=true_ that the multiplexer uses to not run _build-test_ in every iteration, relying on that this has already been  done by the build task. This is a performance optimisation that can be especially effective in fast tests.
It would be ideal to have the initial multiplexer behavior restored, but we can always run _ant build-test_ at the beginning of every multiplexer runner while still not running it on every iteration. This seems enough to keep the multiplexer working but it requires some extra builds and therefore higher costs.

The goal of this ticket is to find the root of this failure and fix the multiplexer either by restoring its initial flow or adding _ant build-test_ at the beginning of every multiplexer runner, if there is no more effective solution.
Bug: Probabilistic diff to sample partitions for diff testing based on probability.
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 17/Sep/21 18:12
Resolved: 25/Oct/21 15:44

Probabilistic diff allows us to sample partitions randomly while running diff tests. It takes new config parameter `partition_sampling_probability ` that ranges between (0-1) and samples partitions based on this probability. The default value for this config property is 1 which means that all the partitions will be diffed. The partitions that are selected are also based on the JobId, for a given sampling probability and JobId we always diff on same partitions.This helps in reproducing any issues that one might run into. Probabilistic diff allows us to run diff jobs on large clusters by sampling some partitions.
Bug: Number of dtest are flaky due to timeout
Status: Resolved
Priority: Normal
Resolution: Invalid
Created: 14/Sep/21 08:25
Resolved: 20/Oct/21 17:08

{{test_multiple_repair}} of {{repair_tests.incremental_repair_test.TestIncRepair}} has failed on CircleCI build and was identified as flaky by CircleCI. See [the failure|https://app.circleci.com/pipelines/github/k-rus/cassandra/10/workflows/846bfcdc-b33e-4e57-9252-56ef445d115a/jobs/92/tests#failed-test-0]

The error:

{code:python}
>           raise self._final_exception
E           cassandra.OperationTimedOut: errors={<Host: 127.0.0.3:9042 datacenter1>: ConnectionShutdown('Connection to 127.0.0.3:9042 was closed',)}, last_host=127.0.0.1:9042

../env3.6/src/cassandra-driver/cassandra/cluster.py:4894: OperationTimedOut
{code}

Similarly {{test_simultaneous_bootstrap}} from {{bootstrap_test.TestBootstrap}} failed in a CircleCI build and was identified as flaky by CircleCI. See for example [this build|https://app.circleci.com/pipelines/github/k-rus/cassandra/16/workflows/9987f757-93f3-4c57-af73-09f4b217ee49/jobs/161/tests#failed-test-0]. The same timeout error as above.
Bug: Conditional update on super column table returns too many rows
Status: Open
Priority: Normal
Created: 01/Jul/21 15:50

We have a (dense) supercolumn table that we're trying to upgrade from 2.2 to 3.x. On this table we perform conditional updates on one of the values using a CQL query. In 2.2 this works as expected: the query returns either a single-column row with {{true}}, or a two-column row with {{false}} and the current value.

In 3.x this query is internally rewritten to work on a map, using a {{Maps.SetterByKey}} operation. The update itself is applied correctly, but when the condition fails and the update is not applied, the query returns all values in the supercolumn/map instead of just the value of the subcolumn/key from the where clause.

In particular, since it returns _just_ the values, and not the keys/mapping, there's no way to know which of the values is the value of the row we're trying to update.

 
{code:java}
– Super column table (created through Thrift)
 CREATE TABLE store.shopping_items (
 key text,
 column1 text,
 column2 text,
 "" map<text, text>,
 value text,
 PRIMARY KEY (key, column1, column2)
 ) WITH COMPACT STORAGE;
– Create some data
 cqlsh:store> INSERT INTO shopping_items (key, column1, column2, value) VALUES ('item1', 'default', 'id', '1');
 cqlsh:store> INSERT INTO shopping_items (key, column1, column2, value) VALUES ('item1', 'default', 'color', 'blue');
– This query returns multiple rows
 cqlsh:store> UPDATE shopping_items SET value ='2' WHERE key ='item1' AND column1 = 'default' AND column2 = 'id' IF value = null;
[applied] | value
 ----------+-----------
 False | 'blue'
 False | '1'
{code}
 

See the attached patch for a test that succeeds on 2.2, but fails with the described behavior on 3.0 and on the latest 3.11.
Bug: sstableverify options aren't correct on the website
Status: Triage Needed
Priority: Normal
Created: 28/Sep/21 16:45

sstableverify options on the cassandra website leave out many options for the tool.

Steps to repro
1. Go to apache cassandra website - https://cassandra.apache.org/doc/latest/cassandra/tools/sstable/sstableverify.html
2. Look under usaage

Result
We have debug, extended, help and verbose options.

Expected:
That the website include other supported options including...
1. Check version
2. Mutate Repair status (whether to mutate repair status)
3. Quick
4. Token range support
Bug: Wrong cqlsh python library location in cassandra-3.11.11-1 rhel packages 
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 30/Jul/21 12:14
Resolved: 03/Sep/21 18:52

cqlsh does not work because cqlshlib is in wrong location while I think it should be in python2.7 for cassandra-3.11

cassandra.spec seems to define python interpreter to /usr/bin/python so I think build environment has been changed after 3.11.10 so /usr/bin/python points to python3 instead of python2.

cassandra-3.11.10 did have chqlshlib in python2.7 site-packages
{noformat}
$ rpm -qpl cassandra-3.11.11-1.noarch.rpm |grep cql
warning: cassandra-3.11.11-1.noarch.rpm: Header V4 RSA/SHA512 Signature, key ID 0b84c041: NOKEY
/etc/cassandra/default.conf/cqlshrc.sample
/usr/bin/cqlsh
/usr/bin/cqlsh.py
/usr/bin/debug-cql
/usr/lib/python3.6/site-packages/cqlshlib
/usr/lib/python3.6/site-packages/cqlshlib/__init__.py
/usr/lib/python3.6/site-packages/cqlshlib/copyutil.py
/usr/lib/python3.6/site-packages/cqlshlib/cql3handling.py
/usr/lib/python3.6/site-packages/cqlshlib/cqlhandling.py
/usr/lib/python3.6/site-packages/cqlshlib/cqlshhandling.py
/usr/lib/python3.6/site-packages/cqlshlib/displaying.py
/usr/lib/python3.6/site-packages/cqlshlib/formatting.py
/usr/lib/python3.6/site-packages/cqlshlib/helptopics.py
/usr/lib/python3.6/site-packages/cqlshlib/pylexotron.py
/usr/lib/python3.6/site-packages/cqlshlib/saferscanner.py
/usr/lib/python3.6/site-packages/cqlshlib/sslhandling.py
/usr/lib/python3.6/site-packages/cqlshlib/tracing.py
/usr/lib/python3.6/site-packages/cqlshlib/util.py
/usr/lib/python3.6/site-packages/cqlshlib/wcwidth.py
{noformat}
 

Pull request to cassandra-3.11: https://github.com/apache/cassandra/pull/1124
Bug: Broken Pipe exception while replacing a failed node
Status: Resolved
Priority: Normal
Resolution: Invalid
Created: 28/Sep/21 16:56
Resolved: 28/Sep/21 16:58

We are encountering the following error:
{code:java}
ERROR [STREAM-OUT-/NewNode] 2021-09-26 14:44:06,554 StreamSession.java:470 - [Stream #23a2c560-1ed5-11ec-8351-2f2e5cc09cec] Streaming error occurred
java.io.IOException: Broken pipe
	at sun.nio.ch.FileChannelImpl.transferTo0(Native Method) ~[na:1.7.0_67]
	at sun.nio.ch.FileChannelImpl.transferToDirectly(FileChannelImpl.java:433) ~[na:1.7.0_67]
	at sun.nio.ch.FileChannelImpl.transferTo(FileChannelImpl.java:565) ~[na:1.7.0_67]
	at org.apache.cassandra.streaming.compress.CompressedStreamWriter.write(CompressedStreamWriter.java:74) ~[apache-cassandra-2.1.1.jar:2.1.1]
	at org.apache.cassandra.streaming.messages.OutgoingFileMessage$1.serialize(OutgoingFileMessage.java:56) ~[apache-cassandra-2.1.1.jar:2.1.1]
	at org.apache.cassandra.streaming.messages.OutgoingFileMessage$1.serialize(OutgoingFileMessage.java:40) ~[apache-cassandra-2.1.1.jar:2.1.1]
	at org.apache.cassandra.streaming.messages.StreamMessage.serialize(StreamMessage.java:45) ~[apache-cassandra-2.1.1.jar:2.1.1]
	at org.apache.cassandra.streaming.ConnectionHandler$OutgoingMessageHandler.sendMessage(ConnectionHandler.java:346) [apache-cassandra-2.1.1.jar:2.1.1]
	at org.apache.cassandra.streaming.ConnectionHandler$OutgoingMessageHandler.run(ConnectionHandler.java:318) [apache-cassandra-2.1.1.jar:2.1.1]
	at java.lang.Thread.run(Thread.java:745) [na:1.7.0_67]
INFO  [STREAM-OUT-/NewNode] 2021-09-26 14:44:06,559 StreamResultFuture.java:180 - [Stream #23a2c560-1ed5-11ec-8351-2f2e5cc09cec] Session with /NewNode is complete
WARN  [STREAM-OUT-/NewNode] 2021-09-26 14:44:06,560 StreamResultFuture.java:207 - [Stream #23a2c560-1ed5-11ec-8351-2f2e5cc09cec] Stream failed
{code}
approximately 15 minutes into bootstrapping a replacement for a failed node into our 10 node ring. This appears to be preventing the new node from successfully joining the ring. When one of the nodes it is streaming data from encounters the aforementioned broken pipe exception, there are no corresponding errors logged by the new node. We're wondering if this might be related to, or a duplicate of [CASSANDRA-10961|https://issues.apache.org/jira/browse/CASSANDRA-10961] however we are not seeing the "Not enough bytes" error on the new node.

 Context:
 * All nodes in the cluster are running 2.1.1 currently
 * The cluster is currently down a node, leaving patch upgrade options to verify a fix by the linked (and possibly related) issue unclear, as this would require a simultaneous bootstrap and upgrade on the new node
 * We've restarted this process numerous times with the same result
 * The replication factor is set to 3
 * Reads and writes both require quorum
 * Each node has about 1.5TB of data
Bug: sstableverify doesn't fully suport verifying token range
Status: Triage Needed
Priority: Normal
Created: 28/Sep/21 16:48

sstableverify offers the abiltiy to verify that a given token range is valid, however, it specifically doesn't seem to trigger any actual testing.

Steps to Repro
1. run sstable verify against an sstable and use the option to include no token range that is covered by the table...

sstableverify -t0,1 ks1 workingtable


Result
Even though none of the elements are valid for the range output code is 0 (no error).

Expected
that the verification step would complain about tokens not found in the range
Bug: replace_address does not work in 3.11.10
Status: Resolved
Priority: Normal
Resolution: Duplicate
Created: 27/Sep/21 13:50
Resolved: 27/Sep/21 13:53

We have a 30 node setup with four DCs. In one DC we had a failed node (cass04). We built a new node, same version of cass. Same rackdc as the failed node, used the same IP as the failed node, and added replace_address=<ip of cass04>.

The node got to joining, then exited with something about can't contact any seeds. All of the seed nodes had the following in their logs:

WARN [MigrationStage:1] 2021-09-27 09:46:34,806 MigrationCoordinator.java:426 - Can't send schema pull request: node /10.10.4.124 is down.

I watched the failuredetector on the seed nodes and it went to zero when the new cass04 started coming up, so they knew it was up. My guess is they were refusing to send because gossip said cass04 was down.

I tried changing the IP to a different IP and used replace_address with the IP of the failed node, and the replacement node kept complaining that it could not get the schema from the failed node. It seems this has been fixed in 3.11.11

So in this situation, what's the best way to replace a failed node in 3.11.10? nodetool removenode of the dead node?
Bug: Fix org.apache.cassandra.concurrent.LongSharedExecutorPoolTest.testPromptnessOfExecution
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 17/Sep/21 21:47
Resolved: 24/Sep/21 17:10

org.apache.cassandra.concurrent.LongSharedExecutorPoolTest.testPromptnessOfExecution fails in [3.11|https://jenkins-cm4.apache.org/job/Cassandra-devbranch/1119/testReport/junit/org.apache.cassandra.concurrent/LongSharedExecutorPoolTest/testPromptnessOfExecution/]
h3.  
{code:java}
Stacktrace
junit.framework.AssertionFailedError at org.apache.cassandra.concurrent.LongSharedExecutorPoolTest.testPromptnessOfExecution(LongSharedExecutorPoolTest.java:169) at org.apache.cassandra.concurrent.LongSharedExecutorPoolTest.testPromptnessOfExecution(LongSharedExecutorPoolTest.java:102)

Standard Output
Completed 0K batches with 0.0M events Running for 120s with load multiplier 0.5

Standard Error
SLF4J: The following set of substitute loggers may have been accessed SLF4J: during the initialization phase. Logging calls during this SLF4J: phase were not honored. However, subsequent logging calls to these SLF4J: loggers will work as normally expected. SLF4J: See also
http://www.slf4j.org/codes.html#substituteLogger
SLF4J: org.apache.cassandra.LogbackStatusListener
{code}
Bug: python dest Failure: scrub_test.py::TestScrubIndexes::test_scrub_collections_table
Status: Resolved
Priority: Normal
Resolution: Duplicate
Created: 24/Sep/21 14:31
Resolved: 24/Sep/21 14:35

scrub_test.py::TestScrubIndexes::test_scrub_collections_table

Saw failure on CASSANDRA-12988; confirmed failure locally and also fails on current trunk.

 

Seeing multiple stack traces come out of it. Here's one:

{code}
ERROR [CompactionExecutor:2] 2021-09-24 10:29:18,505 CassandraDaemon.java:581 - Exception in thread Thread[CompactionExecutor:2,1,main]

java.io.IOError: org.apache.cassandra.serializers.MarshalException: Unexpected extraneous bytes after list value

        at org.apache.cassandra.db.compaction.Scrubber.throwIfCannotContinue(Scrubber.java:449)

        at org.apache.cassandra.db.compaction.Scrubber.scrub(Scrubber.java:272)

        at org.apache.cassandra.db.compaction.CompactionManager.scrubOne(CompactionManager.java:1159)

        at org.apache.cassandra.db.compaction.CompactionManager$3.execute(CompactionManager.java:459)

        at org.apache.cassandra.db.compaction.CompactionManager$2.call(CompactionManager.java:379)

        at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)

        at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)

        at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)

        at io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)

        at java.base/java.lang.Thread.run(Thread.java:829)

Caused by: org.apache.cassandra.serializers.MarshalException: Unexpected extraneous bytes after list value

        at org.apache.cassandra.serializers.ListSerializer.validateForNativeProtocol(ListSerializer.java:82)

        at org.apache.cassandra.serializers.CollectionSerializer.validate(CollectionSerializer.java:66)

        at org.apache.cassandra.db.marshal.AbstractType.validate(AbstractType.java:193)

        at org.apache.cassandra.db.marshal.AbstractType.validate(AbstractType.java:188)

        at org.apache.cassandra.db.compaction.Scrubber.scrub(Scrubber.java:263)

        ... 8 common frames omitted
{code}
Bug: Fix org.apache.cassandra.cql3.ViewTest.testTruncateWhileBuilding 
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 17/Sep/21 21:46
Resolved: 24/Sep/21 10:52

[org.apache.cassandra.cql3.ViewTest.testTruncateWhileBuilding|https://jenkins-cm4.apache.org/job/Cassandra-devbranch/1119/testReport/junit/org.apache.cassandra.cql3/ViewTest/testTruncateWhileBuilding/]  fails in 3.11

 
{code:java}
Error Message
expected:<0> but was:<1>

Stacktrace
junit.framework.AssertionFailedError: expected:<0> but was:<1> at org.apache.cassandra.Util.spinAssertEquals(Util.java:575) at org.apache.cassandra.cql3.ViewTest.testTruncateWhileBuilding(ViewTest.java:1656) at org.jboss.byteman.contrib.bmunit.BMUnitRunner$9.evaluate(BMUnitRunner.java:342) at org.jboss.byteman.contrib.bmunit.BMUnitRunner$6.evaluate(BMUnitRunner.java:241) at org.jboss.byteman.contrib.bmunit.BMUnitRunner$1.evaluate(BMUnitRunner.java:75)
{code}