av9ash/GitBugs huggingface dataset:
Bug: BLOG - Presenter's name misspelt in World Party Talks & Sponsors announcement
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 30/Jun/22 07:11
Resolved: 30/Jun/22 07:29

Paulo Motta's name is misspelt in the [World Party blog post|https://cassandra.apache.org/_/blog/Talks-and-Sponsors-Announced-for-Cassandra-World-Party-2022.html]:

bq. Explore recent improvements to snapshots in Apache Cassandra 4.1 with committer, *Paolo Motta*. Learn about auto snapshot cleanup and the refactoring of the legacy snapshot module.
Bug: WEBSITE - June 2022 blog "Talks & Sponsors Announced for Cassandra World Party 2022"
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 28/Jun/22 17:37
Resolved: 29/Jun/22 13:32

This ticket is to capture the work associated with publishing the June 2022 blog "Talks & Sponsors Announced for Cassandra World Party 2022"

If this blog cannot be published by the *June 29, 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: Endless corrupted sstable after EC2 image restore from AMI backup
Status: Resolved
Priority: Normal
Resolution: Invalid
Created: 28/Jun/22 05:48
Resolved: 28/Jun/22 11:07

Cassandra version 3.11.4, many corrupted sstable files showing in system.log after service restart, and we tried to use AMI backup to restore EC2 server, but the corrupted message showed up too, we tried everything, no matter nodetool scrub, sstablescrub, remove corrupted files then repair, seems corrupted files won't stop to show up.

Is there anyone have encounter this before? Any help won't be much thankful.
Bug: netty-all 4.0.44 is affected by CVE-2020-7238
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 17/Jun/22 13:59
Resolved: 21/Jun/22 14:49

{noformat}
Dependency-Check Failure:
One or more dependencies were identified with vulnerabilities that have a CVSS score greater than or equal to '1.0': 
netty-all-4.0.44.Final.jar: CVE-2020-7238
{noformat}

Similar to CASSANDRA-17633, the HTTP request smuggling vulnerabilities continue.
Bug: Clarify intent when replaying hint files "partially"
Status: Triage Needed
Priority: Normal
Created: 21/Jun/22 22:08

As part of CASSANDRA-6230, hints were redesigned to come from files.  As part of this, we log when the hint files are dispatched.

See https://github.com/apache/cassandra/blob/cassandra-4.1/src/java/org/apache/cassandra/hints/HintsDispatchExecutor.java#L318

{code}
logger.info("Finished hinted handoff of file {} to endpoint {}: {}, partially", descriptor.fileName(), address, hostId);
{code}

This has caused some confusion among some users who wonder whether their files were only partially replayed and whether data is consistent.

This ticket is to clarify in the log statement itself or document in the official docs what is meant by {{partially}}.

My understanding is that it's really that sometimes when shutting down, all of the file metadata isn't written so it replays the file anyway.  Is that right?  I wasn't sure about the dispatch failure and what that means in practice.

CC [~aleksey]
Bug: Javadocs random error
Status: Triage Needed
Priority: Normal
Created: 23/Jun/22 05:24

We have noticed, upon generating artifacts in CI, we sometimes get random javadoc errors such as:

{noformat}
09:24:40   [javadoc] /home/build/cassandra/src/java/org/apache/cassandra/db/marshal/ValueAccessor.java:409: error: no tag name after @
09:24:40   [javadoc]      * lexicographically compare {@param left} to {@param right}
{noformat}

or

{{AlterTableStatement.java:135: error: text not allowed in element}}

Also it would be good all output is directed to a file.
Bug: Add Driver Version to Cassandra audit logs
Status: Triage Needed
Priority: Normal
Created: 22/Jun/22 15:20

When auditing access to Cassandra, it would be helpful to include (if provided) the version of the driver being used i.e [https://cassandra.apache.org/doc/latest/cassandra/operating/audit_logging.html#what-does-audit-logging-logs]
Bug: WEBSITE - June 2022 blog "Apache Cassandra 4.1 Features: Authentication Plugin Support for CQLSH"
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 21/Jun/22 18:57
Resolved: 22/Jun/22 05:56

This ticket is to capture the work associated with publishing the June 2022 blog "Apache Cassandra 4.1 Features: Authentication Plugin Support for CQLSH"

If this blog cannot be published by the *June 23, 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: StorageService read threshold get methods throw NullPointerException due to not handling null configs
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 02/May/22 17:26
Resolved: 10/May/22 19:45

org.apache.cassandra.service.StorageService#getCoordinatorLargeReadWarnThreshold and other similar get methods touch the following null configs

{code}
public volatile DataStorageSpec coordinator_read_size_warn_threshold = null;
public volatile DataStorageSpec coordinator_read_size_fail_threshold = null;
public volatile DataStorageSpec local_read_size_warn_threshold = null;
public volatile DataStorageSpec local_read_size_fail_threshold = null;
public volatile DataStorageSpec row_index_read_size_warn_threshold = null;
public volatile DataStorageSpec row_index_read_size_fail_threshold = null
{code}

Null is a valid state for these configs, so null must be handled in the get methods; they currently are not and throw NullPointerException when accessed via JMX
Bug: jvm-dtest unhandled exceptions failing the test no longer work
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 13/Apr/22 02:52
Resolved: 13/May/22 17:31

Seems that ([CASSANDRA-16925] CEP-10 Phase 1: Mockable Task Execution) refactored and avoided using AbstractCluster.uncaughtException, this means that the logic to detect unexpected exceptions to fail tests no longer works.
Bug: jvm-dtest upgrade tests run all supported pairs of upgrades between from/to but does not actually test all patches from/to
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 23/May/22 21:22
Resolved: 06/Jun/22 21:53

The current upgrade from/to logic is based off a list filter on from/to pairs, and runs the test multiple times for each pair; this does not actually validate that the different paths upgrade cleanly.

Instead, we need to test each supported path; example 3.0 -> 4.2

{code}
3.0.28 -> [4.2]
3.0.28 -> [3.11.14, 4.2]
3.0.28 -> [4.1-alpha1, 4.2]
3.0.28 -> [4.0.5, 4.2]
3.0.28 -> [3.11.14, 4.1-alpha1, 4.2]
3.0.28 -> [3.11.14, 4.0.5, 4.2]
3.0.28 -> [4.0.5, 4.1-alpha1, 4.2]
3.0.28 -> [3.11.14, 4.0.5, 4.1-alpha1, 4.2]
{code}
Bug: jvm-dtest upgrade failures due to 3.x Ping not allowing serialize
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 24/May/22 21:43
Resolved: 25/May/22 21:11

trunk jvm upgrade tests periodically fail due to the ping message not being able to be serialized on 3.x branches.  We need support for jvm-dtest even if we ignore the messages.

{code}
Suppressed: java.lang.UnsupportedOperationException
		at org.apache.cassandra.net.PingMessage$PingMessageSerializer.serialize(PingMessage.java:45)
		at org.apache.cassandra.net.PingMessage$PingMessageSerializer.serialize(PingMessage.java:41)
		at org.apache.cassandra.distributed.impl.Instance.serializeMessage(Instance.java:362)
		at org.apache.cassandra.distributed.impl.Instance$1.allowIncomingMessage(Instance.java:302)
		at org.apache.cassandra.net.MessagingService.receive(MessagingService.java:866)
		at org.apache.cassandra.net.IncomingTcpConnection.receiveMessage(IncomingTcpConnection.java:224)
		at org.apache.cassandra.net.IncomingTcpConnection.receiveMessages(IncomingTcpConnection.java:193)
		at org.apache.cassandra.net.IncomingTcpConnection.run(IncomingTcpConnection.java:96)
{code}
Bug: WEBSITE - June 2022 blog "Apache Cassandra 4.1: New SSTable Identifiers"
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 13/Jun/22 18:03
Resolved: 16/Jun/22 06:22

This ticket is to capture the work associated with publishing the June 2022 blog "Apache Cassandra 4.1: New SSTable Identifiers"

If this blog cannot be published by the *June 16, 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: index read is from one node when authenticator is passwordAuthenticator
Status: Triage Needed
Priority: Normal
Created: 06/Jun/22 02:26

I have a cluster which replication_factor is 3 like:
{code:java}
Datacenter: DC1
================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address          Load       Tokens       Owns    Host ID                               Rack
UN  192.168.242.129  271.1 MiB  256          ?       bda86425-b6cd-479d-a410-c9bd8826d505  rack1
UN  192.168.242.134  256.13 MiB  256          ?       a1935992-3443-4f02-9496-23def15d950d  rack1
UN  192.168.242.135  270.81 MiB  256          ?       8031e6fd-6d60-4fb2-8323-14f93f4c1468  rack1
 {code}
While authenticator is passwordAuthenticator，all read disk IO for index reads comes from a node。Read disk IO of other node is 0. it is just like that all index read is from one node. 

By the way, index read connot get from nodetool tablestats of cassandra3.11.x
Bug: Gossip/Decommission tasklock contention on large clusters
Status: Resolved
Priority: Normal
Resolution: Invalid
Created: 10/Jun/22 15:33
Resolved: 10/Jun/22 15:41

Hi,

I am a researcher working on finding scale issues in distributed systems. I have been analyzing Cassandra 4.0.0 and found a potential issue on the Gossip path. The method 'org.apache.cassandra.gms.Gossiper.addLocalApplicationStates' (line 1958) holds the tasklock that could end up in the invocation of getAddressRepplicas, like this (format is [method][lineNumber]):

[org.apache.cassandra.gms.Gossiper.addLocalApplicationStates] [1958]
{{*Type=EXPLICIT_LOCK, start=1960, end=1970 // Lock being held along these lines*}}
{{ [org.apache.cassandra.gms.Gossiper.addLocalApplicationStateInternal][1965]}}
{{  [org.apache.cassandra.gms.Gossiper.doOnChangeNotifications][1950]}}
{{   [org.apache.cassandra.gms.IEndpointStateChangeSubscriber.onChange][1551]}}
{{    [org.apache.cassandra.service.StorageService.onChange][1551]}}
{{     [org.apache.cassandra.service.StorageService.handleStateRemoving][2308]}}
{{      [org.apache.cassandra.service.StorageService.restoreReplicaCount][2921]}}
{{       [org.apache.cassandra.service.StorageService.getChangedReplicasForLeaving][3128]}}
{{        [org.apache.cassandra.locator.AbstractReplicationStrategy.getAddressReplicas][3203]}}
{{         [org.apache.cassandra.locator.AbstractReplicationStrategy.getAddressReplicas][284]}}
{{         *[line=243, dimensions=[Peers * Tokens]] // Approx. Complexity of this loop*}}

 

This seems to be affecting decommission path and the complexity is at least dependent on the number of tokens and peers in the cluster, thus when decommissioning a node with a large number of peers and tokens this path will end up holding the Gossiper's task lock for a long time, which could end up causing flapping.

This is likely to be affecting other 4.x versions too.
Bug: Documentation uses IP:port example for seeds list
Status: Resolved
Priority: Normal
Resolution: Invalid
Created: 09/Jun/22 21:11
Resolved: 09/Jun/22 21:40

The documentation erroneously provides a verbatim snippet of configuration file that suggests you can specify seeds in the form IP:port.

 

See: https://cassandra.apache.org/doc/trunk/cassandra/configuration/cass_yaml_file.html#seed_provider
Bug: WEBSITE - June 2022 blog "Apache Cassandra World Party 2022"
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 08/Jun/22 15:40
Resolved: 09/Jun/22 01:40

This ticket is to capture the work associated with publishing the June 2022 blog "Apache Cassandra World Party 2022"

If this blog cannot be published by the *June 9, 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: Fix flaky python-tests due to connection getting closed
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 03/May/22 18:48
Resolved: 01/Jun/22 17:57

We log unknown exceptions at the networking level, which includes case where the remote side closes the connection (such as the cases caused by shutting down), depending on how quickly the instances shutdown, this could cause python-dtest to fail for random tests with a message such as

{code}
Unexpected error found in node logs (see stdout for full details). Errors: [WARN  [epollEventLoopGroup-5-9] 2022-05-03T16:47:03,800 ExceptionHandlers.java:134 - Unknown exception in client networking
io.netty.channel.unix.Errors$NativeIoException: writeAddress(..) failed: Connection reset by peer, WARN  [epollEventLoopGroup-5-9] 2022-05-03T16:47:03,800 ExceptionHandlers.java:134 - Unknown exception in client networking
io.netty.channel.unix.Errors$NativeIoException: writeAddress(..) failed: Connection reset by peer]
{code}
Bug: WEBSITE - June 2022 blog "Apache Cassandra Changelog #16"
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 31/May/22 17:02
Resolved: 01/Jun/22 03:56

This ticket is to capture the work associated with publishing the May 2022 blog "Apache Cassandra Changelog #16"

If this blog cannot be published by the *June 2, 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: races/leaks in SSTableReader::GlobalTidy
Status: Patch Available
Priority: Normal
Created: 04/Apr/22 12:17

In Cassandra 4.0/3.11 there are at least two races in SSTableReader::GlobalTidy

One is a get/get race, explicitly handled as an assertion in:

[http://github.com/apache/cassandra/blob/c22accc46458d0a583afcf6a980f731cdcc94465/src/java/org/apache/cassandra/io/sstable/format/SSTableReader.java#L2199-L2204]

and it looks like "ok, it's a problem, but let's just not fix it"

The other one is get/tidy race between 

[http://github.com/apache/cassandra/blob/c22accc46458d0a583afcf6a980f731cdcc94465/src/java/org/apache/cassandra/io/sstable/format/SSTableReader.java#L2194-L2196]

and

[http://github.com/apache/cassandra/blob/c22accc46458d0a583afcf6a980f731cdcc94465/src/java/org/apache/cassandra/io/sstable/format/SSTableReader.java#L2174-L2175]

 

The second one can be easily hit by adding a small delay at the beginning of `tidy()` method (say, 20ms) and running `LongStreamingTest` (and actually such failure is what prompted the investigation of GlobalTidy correctness)

There was an attempt on `trunk` to fix these two races.
The details are not clear to me, and it all looks quite weird. I might be mistaken, but as far as I can see the relevant changes were introduced in:
[https://github.com/apache/cassandra/commit/31bea0b0d41e4e81095f0d088094f03db14af490]
that is piggybacked on a huge change in CASSANDRA-17008, without a separate ticket or any sort of qa.

As far as I can see this attempt changes the first race into a leak, and the second race to another race, this time allowing to have multiple GlobalTidy objects for the same sstable (and, as a result, a premature running of obsoletion code).

I'll follow up with PRs for relevant branches etc etc
Bug: Link to dtests is incorrect on the website
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 25/May/22 15:34
Resolved: 28/May/22 10:42

This page: https://cassandra.apache.org/_/development/ci.html

links to https://github.com/riptano/cassandra-dtest but should link https://github.com/apache/cassandra-dtest
Bug: repair vtables should expose a completed field due to lack of filtering options in CQL
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 04/Apr/22 22:19
Resolved: 06/Apr/22 20:12

To find repairs actively running, we need to run the following command

{code}
SELECT * 
FROM system_views.repairs 
WHERE status IN ('setup', 'start', 'prepare_start', 'prepare_complete', 'repair_start', 'repair_complete')
ALLOW FILTERING;
{code}

This is annoying, and a problem if more states are added in the future…. Ideally we would do one of the following

NOT IN:

{code}
status NOT IN (’success’, ’skip’, ‘failure’)
{code}

But this is not currently supported

{code}
cqlsh> select * from system_views.repairs WHERE duration_millis > 10 AND status NOT IN ('success', 'failure') ALLOW FILTERING;
SyntaxException: line 1:73 no viable alternative at input 'NOT' (...WHERE duration_millis > 10 AND [status] NOT...)
{code}

Not Equals
{code}
cqlsh> select * from system_views.repairs WHERE duration_millis > 10 AND status != 'success' AND status !='failure' ALLOW FILTERING;
InvalidRequest: Error from server: code=2200 [Invalid query] message="Unsupported "!=" relation: status != 'success'"
{code}

This also fails

{code}
cqlsh> select * from system_views.repairs WHERE duration_millis > 10 AND status != 'success' AND status !='failure' ALLOW FILTERING;
InvalidRequest: Error from server: code=2200 [Invalid query] message="Unsupported "!=" relation: status != 'success'"
{code}

NULL Checking

{code}
state_success_timestamp IS NULL AND state_failure_timestamp IS NULL
— OR
state_success_timestamp=null AND state_failure_timestamp=null
{code}

This also fails

{code}
cqlsh> select * from system_views.repairs WHERE duration_millis > 10 AND state_success_timestamp IS NULL ALLOW FILTERING;
SyntaxException: line 1:93 mismatched input 'NULL' expecting K_NOT (...> 10 AND state_success_timestamp IS [NULL]…)
cqlsh> select * from system_views.repairs WHERE duration_millis > 10 AND state_success_timestamp=null ALLOW FILTERING;
InvalidRequest: Error from server: code=2200 [Invalid query] message="Unsupported null value for column state_success_timestamp"
{code}


Given that our filtering logic is restrictive, we need a column to expose if completed or not, so filtering works
Bug: Fix CircleCI Midres config
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 19/Apr/22 22:41
Resolved: 04/May/22 16:08

During CircleCI addition of a new job to the config, the midres file got messy. Two of the immediate issues (but we need to verify all jobs will use the right executors and resources):
 * the new job needs to use higher parallelism as the original in-jvm job
 *  j8_dtests_with_vnodes should get from midres 50 large but currently midres makes it run with 25 and medium which fails around 100 tests
Bug: WEBSITE - May 2022 blog "Apache Cassandra 4.1 Features: Guardrails Framework"
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 11/May/22 16:43
Resolved: 12/May/22 12:11

This ticket is to capture the work associated with publishing the May 2022 blog "Apache Cassandra 4.1 Features: Guardrails Framework"

If this blog cannot be published by the *May 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: Clean up schema migration coordinator and tests
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 06/Apr/22 23:28
Resolved: 08/Apr/22 20:50

The schema migration coordinator was created to offload
the tracking and retrieval of schemas present across the
cluster when bootstrapping (CASSANDRA-15158).

The in-jvm dtests Instance startup was not correctly modified
to override the uptime calculation, and there are some
system properties that can be moved to CassandraRelevantProperties
so that they appear in the system virtual tables.
Bug: WEBSITE - Fix vanity image on 4.1 Guardrails blog post
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 13/May/22 00:31
Resolved: 13/May/22 01:15

The image attached to the  [Apache Cassandra 4.1 Features: Guardrails Framework|https://cassandra.staged.apache.org/_/blog/Apache-Cassandra-4.1-Features-Guardrails-Framework.html] blog post (CASSANDRA-17621) is too large for the page.

It needs to be replaced with the attached image supplied by [~Calico]:

!apache-cassandra-4.1-features-guardrails-framework-unsplash-jj-ying.jpg|width=300!
Bug: Clients using JMX are unable to handle non-standard java types but we leak this into our Exceptions
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 18/May/22 19:20
Resolved: 19/May/22 18:52

This is follow up ticket on CASSANDRA-17527 and CASSANDRA-17580. 
CASSANDRA-17580 was decided to be a backup non-default option for users who want to be 100% sure there are no leaked Cassandra exceptions. In that sense I will fix here all known ConfigurationExceptions that need to be thrown as IllegalArgumentException for the default behavior as we were always supposed to do that.
Bug: Add guardrail to disallow creation of new COMPACT STORAGE tables
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 05/Apr/22 15:48
Resolved: 07/Apr/22 18:11

While we have the ability to toggle whether we allow the {{DROP COMPACT STORAGE}} operation, we don't have a way system-wide to disable _creation_ of new COMPACT STORAGE tables.

A guardrail for this would be nice.
Bug: Implement nodetool command to list data directories of existing tables
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 20/Apr/22 20:03
Resolved: 22/Apr/22 12:58

When a table is created, dropped and re-created with the same name, directories remain within data paths. Operators may be challenged finding out which directories belong to existing tables and which may be subject to removal. However, the information is available in CQL as well as in MBeans via JMX, a convenient access to this information is still missing.

My proposal is a new nodetool subcommand allowing to list data paths of all existing tables.
{code}
% bin/nodetool datapaths -- example
Keyspace : example
	Table : test
	Paths :
		/var/lib/cassandra/data/example/test-02f5b8d0c0e311ecb327ff24df5ab301

----------------
{code}
Bug: Rename truncate_drop guardrail to drop_truncate_table
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 02/May/22 17:23
Resolved: 06/May/22 15:52

As per discussion on CASSANDRA-17558, we need to rename this guardrail before 4.1 goes out to include the fact that it only applies to tables.

 

This will pave the way for us to add a guardrail to disallow dropping keyspaces in the future.
Bug: Reduce histogram snapshot long[] allocation overhead during speculative read and write threshold updates
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 05/Apr/22 16:10
Resolved: 07/Apr/22 20:34

Every 5 seconds with the default {{read_request_timeout}} (or in the old naming scheme {{{}read_request_timeout_in_ms{}}}), a scheduled task updates the speculation thresholds (for reads and writes) for all active tables. However, there are a few issues with the way we do this:
 
1.) Whether or not the {{SpeculativeRetryPolicy}} implementations in use actually looks at them, we create latency histogram snapshots to pass to {{{}calculateThreshold(){}}}. We could trivially avoid this by having the method take an argument of type {{Sampling}} and build the snapshot only when necessary.
 
2.) The only reason we build the histogram snapshot is to find the new threshold value for the percentile based policies. {{EstimatedHistogramReservoirSnapshot}} creates copies of both the decaying and non-decaying buckets, but we don’t use the non-decaying values at all for percentile calculation. Just avoiding the non-decaying values array creation would cut allocations in half.
 
Given even our snapshots aren’t perfectly consistent, it might also be possible to calculate a percentile value directly from the reservoir’s decaying buckets, although that might be less accurate, as new values could be added to the buckets after a count is calculated.