av9ash/GitBugs huggingface dataset:
Bug: Fix test distributed.test.trackwarnings.TombstoneWarningTest
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 16/Nov/21 19:19
Resolved: 16/Nov/21 22:44

https://app.circleci.com/pipelines/github/dcapwell/cassandra/1103/workflows/9a6767c7-fadf-4d86-9296-e8973167c6fe/jobs/7897

Passed on jdk8 but failed on jdk11.

Failures

{code}
junit.framework.AssertionFailedError: expected:<...7.0.0.1=1, /127.0.0.[2=1, /127.0.0.]3=1}> but was:<...7.0.0.1=1, /127.0.0.[]3=1}>
	at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
	at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
	at java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
	at org.apache.cassandra.distributed.test.trackwarnings.TombstoneWarningTest.failThreshold(TombstoneWarningTest.java:233)
	at org.apache.cassandra.distributed.test.trackwarnings.TombstoneWarningTest.failThresholdScan(TombstoneWarningTest.java:189)
	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}

and

{code}
junit.framework.AssertionFailedError: [global aborts] expected:<[2]L> but was:<[3]L>
	at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
	at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
	at java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
	at org.apache.cassandra.distributed.test.trackwarnings.TombstoneWarningTest.assertWarnAborts(TombstoneWarningTest.java:294)
	at org.apache.cassandra.distributed.test.trackwarnings.TombstoneWarningTest.failThreshold(TombstoneWarningTest.java:219)
	at org.apache.cassandra.distributed.test.trackwarnings.TombstoneWarningTest.failThresholdSinglePartition(TombstoneWarningTest.java:183)
	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: Fix test NetstatsBootstrapWithEntireSSTablesCompressionStreamingTest#testWithStreamingEntireSSTablesWithoutCompressionWithoutThrottling
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 12/Nov/21 22:55
Resolved: 15/Nov/21 17:33

https://app.circleci.com/pipelines/github/dcapwell/cassandra/1099/workflows/2f08ff99-9ea5-4023-b027-84150efbd2e9/jobs/7850

Found in CASSANDRA-17069.

What I see is that there is a race condition, which is easier to hit when we disable throttling.  If zero-copy-streaming starts and completes within the gap between nodetool calls, then the test fails with a timeout as the expected condition is not seen (waits to see streaming).  We can avoid this by detecting that streaming completed by grepping the logs.
Bug: coordinator_large_read should be actually  coordinator_read_size in cassandra.yaml
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 03/Nov/21 22:05
Resolved: 03/Nov/21 22:35

coordinator_large_read should be actually called coordinator_read_size in cassandra.yaml

After refactoring the name was changed in the test config but not in the default file.

The issue was not caught because track_warnings is currently disabled and commented out.
Bug: Fix test failure: dtest-upgrade.upgrade_tests.upgrade_through_versions_test.TestProtoV3Upgrade_AllVersions_RandomPartitioner_EndsAt_3_11_X_HEAD.test_rolling_upgrade
Status: Resolved
Priority: Normal
Resolution: Duplicate
Created: 28/Oct/21 17:48
Resolved: 09/Nov/21 17:04

!https://ci-cassandra.apache.org/static/a177fe56/images/32x32/health-80plus.png! Failed 28 times in the last 28 runs. Flakiness: 0%, Stability: 0%
 
Example failure: https://ci-cassandra.apache.org/job/Cassandra-trunk/801/testReport/junit/dtest-upgrade.upgrade_tests.upgrade_through_versions_test/TestProtoV3Upgrade_AllVersions_RandomPartitioner_EndsAt_3_11_X_HEAD/test_rolling_upgrade/ 

{code:java}
self = <upgrade_tests.upgrade_through_versions_test.TestProtoV3Upgrade_AllVersions_RandomPartitioner_EndsAt_3_11_X_HEAD object at 0x7fb75c2087c0>

    @pytest.mark.timeout(3000)
    def test_rolling_upgrade(self):
        """
            Test rolling upgrade of the cluster, so we have mixed versions part way through.
            """
>       self.upgrade_scenario(rolling=True)

upgrade_tests/upgrade_through_versions_test.py:320: 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
upgrade_tests/upgrade_through_versions_test.py:398: in upgrade_scenario
    self._check_on_subprocs(self.fixture_dtest_setup.subprocs)
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 

self = <upgrade_tests.upgrade_through_versions_test.TestProtoV3Upgrade_AllVersions_RandomPartitioner_EndsAt_3_11_X_HEAD object at 0x7fb75c2087c0>
subprocs = [<Process name='Process-1' pid=19049 parent=301 stopped exitcode=-SIGKILL daemon>, <Process name='Process-2' pid=19070 parent=301 stopped exitcode=1 daemon>]

    def _check_on_subprocs(self, subprocs):
        """
            Check on given subprocesses.
    
            If any are not alive, we'll go ahead and terminate any remaining alive subprocesses since this test is going to fail.
            """
        subproc_statuses = [s.is_alive() for s in subprocs]
        if not all(subproc_statuses):
            message = "A subprocess has terminated early. Subprocess statuses: "
            for s in subprocs:
                message += "{name} (is_alive: {aliveness}), ".format(name=s.name, aliveness=s.is_alive())
            message += "attempting to terminate remaining subprocesses now."
            self._terminate_subprocs()
>           raise RuntimeError(message)
E           RuntimeError: A subprocess has terminated early. Subprocess statuses: Process-1 (is_alive: True), Process-2 (is_alive: False), attempting to terminate remaining subprocesses now.

upgrade_tests/upgrade_through_versions_test.py:456: RuntimeError
{code}
Bug: Building Cassandra gives a resolver error
Status: Open
Priority: Normal
Created: 02/Nov/21 09:22

Building Cassandra from source with, e.g., {{ant}}, gives following resolver errrors:

{code:java}
[resolver:resolve] The POM for org.perfkit.sjk.parsers:sjk-jfr5:jar:0.5 is invalid, transitive dependencies (if any) will not be available: 2 problems were encountered while building the effective model for org.perfkit.sjk.parsers:sjk-jfr5:0.5
[resolver:resolve] [ERROR] 'dependencies.dependency.systemPath' for com.jrockit.mc:com.jrockit.mc.common:jar must specify an absolute path but is ${jmc5.path}/plugins/com.jrockit.mc.common_${jmc5.version}.jar @ 
[resolver:resolve] [ERROR] 'dependencies.dependency.systemPath' for com.jrockit.mc:com.jrockit.mc.flightrecorder:jar must specify an absolute path but is ${jmc5.path}/plugins/com.jrockit.mc.flightrecorder_${jmc5.version}.jar @ 
[resolver:resolve] The POM for org.perfkit.sjk.parsers:sjk-jfr6:jar:0.7 is invalid, transitive dependencies (if any) will not be available: 2 problems were encountered while building the effective model for org.perfkit.sjk.parsers:sjk-jfr6:0.7
[resolver:resolve] [ERROR] 'dependencies.dependency.systemPath' for com.oracle.jmc:com.oracle.jmc.common:jar must specify an absolute path but is ${jmc6.path}/plugins/com.oracle.jmc.common_${jmc6.version}.jar @ 
[resolver:resolve] [ERROR] 'dependencies.dependency.systemPath' for com.oracle.jmc:com.oracle.jmc.flightrecorder:jar must specify an absolute path but is ${jmc6.path}/plugins/com.oracle.jmc.flightrecorder_${jmc6.version}.jar @ 
[resolver:resolve] The POM for org.perfkit.sjk.parsers:sjk-nps:jar:0.5 is invalid, transitive dependencies (if any) will not be available: 3 problems were encountered while building the effective model for org.perfkit.sjk.parsers:sjk-nps:0.5
[resolver:resolve] [ERROR] 'dependencies.dependency.systemPath' for jdk.org.netbeans:profiler:jar must specify an absolute path but is ${visualvm.path}/profiler/modules/org-netbeans-modules-profiler.jar @ 
[resolver:resolve] [ERROR] 'dependencies.dependency.systemPath' for jdk.org.netbeans:lib-profiler:jar must specify an absolute path but is ${visualvm.path}/profiler/modules/org-netbeans-lib-profiler.jar @ 
[resolver:resolve] [ERROR] 'dependencies.dependency.systemPath' for jdk.org.netbeans:lib-profiler-common:jar must specify an absolute path but is ${visualvm.path}/profiler/modules/org-netbeans-lib-profiler-common.jar @ 
{code}
The actual build succeeds and the build result can be successfully run. However, it is good to fix these errors to avoid confusions and hided problems in future.
Bug: Support adding custom verbs at runtime
Status: Triage Needed
Priority: Normal
Created: 22/Oct/21 21:34

Cassandra already has support for registering custom verbs at build time, but there's value in allowing verbs to be added at runtime since that enables new use cases where it's inconvenient or impossible to modify the Cassandra source.

Additionally, apps that went to register new verbs benefit from running custom code after the default verb handlers execute. This can be achieved with straightforward modifications to the Sink interface (e.g. adding a PostSink class).
Bug: Refactor and support pluggable failure detection
Status: Resolved
Priority: Normal
Resolution: Duplicate
Created: 22/Oct/21 21:03
Resolved: 02/Nov/21 11:39

Making it possible to supply custom failure detectors enables supporting new failure detection algorithms and makes testing using mocks much easier.

The general idea is to introduce a new config parameter, such as org.apache.cassandra.custom_failure_detector_class, that specifies the failure detection class to use.
Bug: Upgrade failure caused by the change of value of `num_token`
Status: Resolved
Priority: Normal
Resolution: Not A Problem
Created: 26/Oct/21 12:57
Resolved: 26/Oct/21 23:05

After shutting down the node(3.11.10), I started the node with the newer version(4.0.0) software and the newer default configuration file (conf/cassandra.yaml) but came across a failure. After changing the value of `num_token` from 16 to 256 (the value in the default configuration file of 3.11.10) in the configuration file, the node can be started successfully with the 4.0.0 software. I wonder whether this should be clear in the corresponding document.
Bug: Refactor and support pluggable cluster membership
Status: Triage Needed
Priority: Normal
Created: 22/Oct/21 21:17

Allowing users to specify a classes that implement a new CustomTokenMetadataProvider class makes cluster membership pluggable (supporting custom code) and makes testing much easier.

Users could specify the cluster membership algorithm using a new config parameter such as org.apache.cassandra.token_metadata_provider_class.
Bug: Endless loop/timeout in ShortReadRowsProtection due to int overflow in ThriftLimits
Status: Open
Priority: Normal
Created: 18/Oct/21 09:11

The result of ThriftLimits.count() can overflow, especially if one of the values is NO_LIMIT (i.e. Integer.MAX_VALUE). This can cause an issue in ShortReadRowsProtection in DataResolver if the count happens to overflow to a negative value, and the replicas actually return some data. The loop calling ShortReadRowsProtection will not exit normally, while the replicas keep returning the same data, until the timeout is exceeded and an exception is raised while waiting for the replica's response.

The following code consistently reproduces the issue on a clustered setup on 3.11. The call to get_range_slices() raises the timeout exception. If the consistency level is changed to ONE, it will return the data just fine. Same if the count in the KeyRange is changed (e.g. to 9_999) so that count * Integer.MAX_VALUE is positive.
{code:java}
Cassandra.Client cassandra = client.getCassandra(keyspaceName);
CfDef cfd = new CfDef(keyspaceName, tableName)
        .setColumn_type("SUPER")
        .setKey_validation_class("UTF8Type")
        .setComparator_type("UTF8Type")
        .setSubcomparator_type("UTF8Type")
        .setDefault_validation_class("UTF8Type");

ByteBuffer key = UTF_8.encode("key");
ColumnParent parent = new ColumnParent(tableName).setSuper_column(UTF_8.encode("Default"));
Column column = new Column(UTF_8.encode("config_value"))
        .setTimestamp(1000 * System.currentTimeMillis())
        .setValue(UTF_8.encode("value"));

SlicePredicate predicate = new SlicePredicate()
        .setColumn_names(singletonList(UTF_8.encode("config_value")));
KeyRange keyRange = new KeyRange()
        .setStart_key(new byte[0])
        .setEnd_key(new byte[0])
        .setCount(10_000);

cassandra.system_add_column_family(cfd);
cassandra.insert(key, parent, column, ConsistencyLevel.QUORUM);
List<KeySlice> slices = cassandra.get_range_slices(parent, predicate, keyRange, ConsistencyLevel.QUORUM);

assertEquals(1, slices.size());

KeySlice slice = slices.get(0);
assertEquals(key, ByteBuffer.wrap(slice.getKey()));
assertEquals(1, slice.getColumnsSize());

Column result = slice.getColumns().get(0).getColumn();
assertNotNull(result);
assertEquals(UTF_8.encode("config_value"), ByteBuffer.wrap(result.getName()));
assertEquals(UTF_8.encode("value"), ByteBuffer.wrap(result.getValue()));
{code}
Bug: Backport snakeyaml 1.26 upgrade
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 08/Oct/21 15:34
Resolved: 15/Oct/21 15:08

In CASSANDRA-16150 snakeyaml was upgraded, but only in the 4.0 line.  We should backport this to 3.11 and 3.0 as well.
Bug: Add minor upgrade/downgrade/mixed mode support in in-jvm dtests
Status: Triage Needed
Priority: Normal
Created: 15/Oct/21 13:57

It should be possible to write in-jvm dtests where we upgrade from an earlier minor version to the current one, and since we support downgrading between minors we should add some tests for that.

If possible it would be nice to provide a new test target running all the in-jvm dtests, but where some random nodes in the in-jvm clusters are running a previous minor version to exercise a mixed mode cluster.

Goal is to be able to catch issues like CASSANDRA-17042 early.
Bug: Fix resource leak due to Files.list
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 14/Oct/21 06:02
Resolved: 14/Oct/21 06:18

Files.list will opend dir and we should close it.

 

see jdk:

the
 * \{@code try}-with-resources construct should be used to ensure that the
 * stream's \{@link Stream#close close} method is invoked after the stream
 * operations are completed.
Bug: Allow configuring max allowable disk usage quota by keyspace
Status: Open
Priority: Normal
Created: 11/Oct/21 15:06

This is a similar idea (basically identical idea; didn't want to steamroll that old ticket w/an update to description etc) to what was raised and closed in CASSANDRA-5394. In multi-tenant situations it can be very helpful to provide disk quotas per Keyspaces for users.

We can do this via a low priority background job that periodically checks disk usage and flips a bit on the Keyspaces when it's over as well as reverts it when things settle back down to prevent needing the read-before-write a hard realtime requirement would introduce. While this would of course allow users to "burst" their usage past that limit in the time window, it would still be sufficient for many use-cases.
Bug: Avoid unnecessary String.format in QueryProcessor when getting stored prepared statement 
Status: Resolved
Priority: Low
Resolution: Fixed
Created: 10/Dec/21 14:16
Resolved: 18/May/23 20:49

In the _QueryProcessor#getStoredPreparedStatement_ if the statement is found in the prepared statements cache, there is always unnecessary string creation using String.format in order to execute the _checkTrue_ assertion. The string construction is necessary only when the queries are not equal.
{code:java}
public static ResultMessage.Prepared getStoredPreparedStatement(String queryString, String clientKeyspace)
throws InvalidRequestException
{
    MD5Digest statementId = computeId(queryString, clientKeyspace);
    Prepared existing = preparedStatements.getIfPresent(statementId);
    if (existing == null)
        return null;

    checkTrue(queryString.equals(existing.rawCQLStatement),
            String.format("MD5 hash collision: query with the same MD5 hash was already prepared. \n Existing: '%s'", existing.rawCQLStatement));
 {code}
Hopefully the JIT can optimize this once the _checkTrue_ is inlined, but it's getting on my nerves as it's popping up on my flame graphs all the time.
Bug: Emit warnings for deprecated parameters (changed names) only once
Status: Resolved
Priority: Low
Resolution: Fixed
Created: 17/Nov/21 20:12
Resolved: 08/Jan/22 20:43

We added backward compatibility for two config parameters in CASSANDRA-17141 to fix a bug but I realized that with the current setup, a warning for deprecated parameter can be logged more than once which is not needed and only introduces noise to the logs. 

I already fixed that in CASSANDRA-15234 where this would lead to a lot of warnings and it is easy to spot. I will backport the tiny fix here too in case we add more parameters, etc; to prevent the potential noise.
Bug: CircleCI dtest multiplexer with MIDRES needs more resources
Status: Resolved
Priority: Low
Resolution: Fixed
Created: 14/Oct/21 16:07
Resolved: 19/Oct/21 10:54

The CircleCI jobs for regular dtests jobs have more resources in MIDRES, which is necessary for some dtests to reliably success. However, the dtest multiplexer uses the same resources for LOWRES and MIDRES.

I think that the dtest multiplexer should always use the same resources as the regular dtests. Using too small resources in the multiplexer can lead to failures that don't reproduce in the regular dtest jobs, like the one we found in [CASSANDRA-16334|https://app.circleci.com/pipelines/github/adelapena/cassandra/1020/workflows/63908694-e4d7-40b1-9418-7a4b87826233/jobs/9422] when trying to repeatedly run a resource-hungry dtest, or like [this other one|https://app.circleci.com/pipelines/github/adelapena/cassandra/1020/workflows/63908694-e4d7-40b1-9418-7a4b87826233/jobs/9422] while running {{test_network_topology}}.

This happens because I forgot to update the diff patch when adding the multiplexer. This doesn't affect HIGHRES because in that case the patch changes the configuration of the test executor, while in MIDRES a new executor is defined.
Bug: Fix rare NPE caused by batchlog replay / node decomission races
Status: Resolved
Priority: Low
Resolution: Fixed
Created: 19/Oct/21 14:47
Resolved: 12/Nov/21 14:46

Batchlog replay process collects addresses of the hosts that have been hinted to, so it can flush hints for them to disk before confirming deletion of the replayed batches. If a node has been decommissioned during replay, however, when the time comes to flush the hints at the very end of replay, {{StorageService.getHostIdForEndpoint()}} will return {{null}} for its address, which will, down the line, cause {{HintsCatalog::get()}} to be invoked with a {{null}} host id argument, causing an NPE.

The simple fix is to check returned host ids for addresses for nulls, and collect hinted host ids instead of hinted addresses.
Bug: Add info how to test with your own CCM branch
Status: Resolved
Priority: Low
Resolution: Fixed
Created: 02/Dec/21 21:15
Resolved: 27/Jan/22 17:25

In CASSANDRA-16688 we solved an issue with ccm and retagging.
It required to remove the -e from the beginning of [this row|https://github.com/apache/cassandra-dtest/blob/trunk/requirements.txt#L9]

But now if someone wants to test with their own ccm branch, they need to add back the -e during testing so that pip3 updates with their branch. Without it, it doesn't update.

*Example:*
{code:java}
-e git+https://github.com/riptano/ccm.git@cassandra-test#egg=ccm
{code}
This is important information and I think we need to add it to at least:
 - our Testing page where dtest runs are mentioned on the website
 - Add a comment in requirements.txt in the dtest repo
We can also update the README files of CCM and DTests but then if something changes we will need to update this info in 4 places which doesn't seem efficient to me.
Bug: Implement graceful paging across tombstones with short-circuit on paging rather than throwing TombstoneOverwhelmingExceptions
Status: Open
Priority: High
Created: 04/Apr/23 18:26

We implemented the hard stop with a {{TombstoneOverwhelmingException}} almost a decade ago since paging across many tombstones was the most common way for nodes to OOM as they iterated across all this data during queries and paging.

With our current implementations and architecture / codebase, we should be able to combine the {{StoppingTransformation}} and existing {{clustering}} blob we pass back to clients to allow clients to optionally page across tombstones when using the async api via the driver and short-circuit a page when they hit the tombstone failure threshold rather than throwing a {{{}TombstoneOverwhelmingException{}}}. This would allow for more flexible data modeling on users' side as well as removing one of the fairly rough edges of our API's we're currently constrained by.

Making sure this is correct will require extensive fuzz-testing of pagination; this should likely happen in the Harry project but we could also have a bespoke model / implementation in the C* codebase we rely on in the interim.

Client warnings at the current default levels would remain; the gap between warn and "short-circuit pages" (100x ratio currently, 1000 vs. 100000) should  be sufficient for clients to take action on their data models well before they hit this limit.
Bug: Restrict the types of objects SnakeYAML is allowed to instantiate
Status: Open
Priority: Normal
Created: 20/Jun/23 13:56

The YAML library used when parsing YAML configuration files in Cassandra by default allows configuration files to trigger instantiating arbitrary objects (which in turn may allow the provider of that value to execute arbitrary code as the cassandra process).

Because Cassandra only accepts configuration files from trusted sources, this is strictly speaking not a security problem. If downstream integrators allow less-trusted users to provide values that are passed into configuration files, it is up to them to validate those do not contain unexpected values. That said, it would be nice to harden against such scenario's.

There was a previous attempt to apply such hardening in CASSANDRA-18150. However, the change in [https://github.com/apache/cassandra/commit/e7f55ab8c3bd6bac4c87354afec231d7237c35b8] is not effective: the class hierarchy is
rather confusing: org.yaml.snakeyaml.constructor.Constructor extends from org.yaml.snakeyaml.constructor.SafeConstructor, but removes some of its safety measures. Notably, it adds back generic constructors:

this.yamlConstructors.put((Object)null, new ConstructYamlObject());
this.yamlClassConstructors.put(NodeId.scalar, new ConstructScalar());
this.yamlClassConstructors.put(NodeId.mapping, new ConstructMapping());
this.yamlClassConstructors.put(NodeId.sequence, new ConstructSequence());

Removing them in Cassandra's YamlConfigurationLoader is not entirely trivial, as
it actually uses the generic constructors.