av9ash/GitBugs huggingface dataset:
Bug: Add support for singletons on CQL collection functions
Status: Review In Progress
Priority: Normal
Created: 02/Dec/22 11:39

CASSANDRA-18060 has added generic CQL functions to get the min, max, sum, avg and number of items in a collection. These functions can only be applied to collection values. The functions throw an {{InvalidRequestEception}} when applied to not-collection values.

CASSANDRA-18078 has been pointed out that those functions could be applied also to not-collection values, considering that the not-collection argument can be considered a collection of a single element. For example:
 * collection_min(7) = collection_min([7]) = collection_min(\{7}) = 7
 * collection_max(7) = collection_max([7]) = collection_max(\{7}) = 7
 * collection_sum(7) = collection_sum([7]) = collection_sum(\{7}) = 7
 * collection_avg(7) = collection_avg([7]) = collection_avg(\{7}) = 7
 * collection_count(7) = collection_count([7]) = collection_count(\{7}) = 1

This would be particularly useful when used in combination with functions such as {{writetime}} and {{{}ttl{}}}. Those functions can return either single values or collections of values depending on whether the column passed as argument is multicell. Thus, users interested on getting the min/max/sum/avg of the writetimes/ttls of a column need to consider the type of the column when choosing what functions they should use. With the proposed change they could just use, for example, {{collection_max(writetime(column))}} regardless of the column type.
Bug: Extend testing for Python DTest test_sstableupgrade
Status: Open
Priority: Normal
Created: 03/Oct/22 15:49

While looking into another problem I noticed the below comment and I did not find expansion of this coverage, the particular test still ends in 3.X. Maybe we test in the in-jvm? To be checked. 
{code:java}
# 4.0 removes back compatibility with pre-3.0 versions, so testing upgradesstables for
# paths from those versions to 4.0 is invalid (and can only fail). There isn't currently
# any difference between the 3.0 and 4.0 sstable format though, but when the version is
# bumped for 4.0, remove the max_version & add a case for testing a 3.0 -> 4.0 upgrade
@since('2.2', max_version='3.X')
def test_sstableupgrade(self):{code}
Bug: Operability improvements around internode_max_message_size[_in_bytes] in 4.0+
Status: Open
Priority: Normal
Created: 09/Nov/22 21:39

There are a few things we could do to make {{internode_max_message_size}} (formerly {{internode_max_message_size_in_bytes}}) a bit more friendly:

1.) If a read fails because of an {{OversizedMessageException}}, it would be nice to emit a client warning. Currently the client gets a {{ReadFailureException}}, surfaced as something like this:

{noformat}
msg="Cassandra failure during read query at consistency QUORUM (3 responses were required but only 0 replica responded, 2 failed)"
query="SELECT key, column1, value FROM ks.tbl WHERE key=? AND column1>? AND column1<=? LIMIT 256;"
stackTrace="com.datastax.driver.core.exceptions.ReadFailureException: Cassandra failure during read query at consistency QUORUM (3 responses were required but only 0 replica responded, 2 failed)
{noformat}

2.) We should add an entry in {{NEWS.txt}} to indicate the possible impact of {{internode_max_message_size_in_bytes}} when upgrading to 4.0+.

3.) {{internode_max_message_size_in_bytes}} / {{internode_max_message_size}} should be settable at runtime via JMX/vtable/etc.
Bug: The source code must obey the avoid star import checkstyle rule
Status: Resolved
Priority: Normal
Resolution: Duplicate
Created: 04/Dec/22 19:23
Resolved: 22/Jan/23 21:25

Cassandra has the code style rules regarding the classes import order: [https://cassandra.apache.org/_/development/code_style.html]

Importing all classes from a package or static members from a class leads to tight coupling between packages or classes and might lead to problems when a new library version introduces name clashes. The advantage of explicitly listing all imports from a package is that you can tell at a glance which class you meant to use, which does reading and refactoring the source code that much easier.


The checkstyle that is already used for checking the source code has a such check and this check may be added to the config both for the production and test source code:
https://checkstyle.sourceforge.io/config_imports.html#AvoidStaticImport

Besides adding a new checkstyle rule it may be more convenient for those community members that are working with the code to reflect the same rule in the IDE's inspection profiles (if it's possible), thus using the 'optimize imports' will produce the same results on each execution as the checkstyle does.


Summary:
- add new checkstyle rule;
- update IDE's appropriate built-in inspections configurations;
- update development code-style web page and wiki;
Bug: improve StartupException related codes
Status: Open
Priority: Normal
Created: 24/Oct/22 11:15

1. We should use the enum: _*ERR_WRONG_MACHINE_STATE*_ and *_ERR_WRONG_DISK_STATE_* to replace the magic number: 1 and 3
{code:java}
exitOrFail(1, e.getMessage(), e.getCause());
exitOrFail(3, "Exception encountered during startup", e);{code}
 

2. Delete the useless field: *_ERR_OUTDATED_SCHEMA_*
Bug: Allow to attach native masking functions to table columns
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 23/Nov/22 12:38
Resolved: 06/Mar/23 13:50

Allow to attach the native masking functions added by CASSANDRA-17941 to table columns, as defined by [CEP-20|https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-20%3A+Dynamic+Data+Masking]. 

{{CREATE TABLE}} statements would look like:
{code}
> CREATE TABLE patients (
      id timeuuid PRIMARY KEY,
      name text MASKED WITH partial(2, 1),
      birth date MASKED WITH default()
      );
> INSERT INTO patients(id, name, birth) VALUES (now(), 'alice', '1982-12-21);
 
> SELECT name, birth FROM patients;
 
 name    | birth
---------+------------
 alXXXXe | 1900-01-01
{code}
{{ALTER TABLE}} statements would look like:
{code}
> ALTER TABLE patients ALTER name MASKED WITH partial(2, 1);
> ALTER TABLE patients ALTER name WITHOUT MASK;
{code}

It won't be possible to use masked columns in the WHERE and IF clauses of SELECT and UPDATE statements.
Bug: WEBSITE - Add new contributor instruction for provisioning a Jira account
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 22/Nov/22 09:57
Resolved: 28/Nov/22 21:02

In an effort to curb spam tickets, there is a new process that new ASF contributors must follow in order to get a Jira account provisioned. Here is an extract of the email announcement from the Infrastructure team:
{quote}As I'm sure most of you are aware, the spam issues on Jira are getting worse. We are seeing spam user creation of over 10,000 accounts per year, and receive many requests per month from project members for help addressing spam complaints. Infra is taking steps to disable public Jira signups.

Infra has developed a self-service tool by which folks on a PMC can request a Jira account for non-ASF contributors...
{quote}
The instruction needs to be added to the following pages:
 * [Contributing to Cassandra|https://cassandra.apache.org/_/development/index.html] page
 * [Contributing Code Changes|https://cassandra.apache.org/_/development/patches.html] (Patches) page
 * [Reporting Bugs|https://cassandra.apache.org/_/bugs.html] page
 * *Reporting Bugs* section of the [Community|https://cassandra.apache.org/_/community.html#how-to-contribute] page
Bug: Update CCM post CASSANDRA-17379
Status: Open
Priority: Normal
Created: 05/Oct/22 20:13

We updated in CASSANDRA-15234 CCM updateconf to enable it to handle overloading of parameters Python upgrade tests. 

This also allows us not to update for 4.1 the Python DTests but exercise the backward compatibility we have in C* in our tests.

Now CASSANDRA-17379 added a few flags to opt in or out for overloading of parameters.

The default points to -Dcassandra.allow_new_old_config_keys=false but this does not affect our tests as CCM handles the overloading in the yaml.
But this is confusing for users and might lead to issues.

We need to bring on par one way or another ccm with the new flags introduced in CASSANDRA-17379

*Until then the recommendation is to use `-Dcassandra.allow_new_old_config_keys=false` and  `-Dcassandra.allow_duplicate_config_keys=false` to prohibit any kind of overloading when using CCM master and CCM released to prevent any confusion.*
Bug: Bug fix for 'wait' time to be in nanoseconds for consistency instead of microseconds
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 02/Dec/22 12:37
Resolved: 07/Dec/22 20:27

While working on benchmarking Paxos improvements in OSS Cassandra, [~benedict] was asked to review the work and thus found that the wait time was input in microseconds but then output incorrectly in the ContentionStrategy.java file, i.e., by summing up a wait time in nanoseconds with another wait time in microseconds (two different units used mistakenly). So, Benedict suggested the fix whereby the output wait time was then enforced to be consistently in nanoseconds.
Bug: CircleCI improvements and parity
Status: Triage Needed
Priority: Normal
Created: 02/Nov/22 16:08

CircleCI not only needs to be in parity with ASF CI if we're using it to validate commits, as we agreed to optionally use it to validate release we need to further raise that bar.

There's a variety of low-hanging fruit and optimizations on the circle env as well as some un-forking and unification to be done to make it a polished first-class CI citizen for those that can fund the paid plan.

This epic is an umbrella placeholder for efforts that are in flight as well as future discussion about the CircleCI environment in the lead up to and after 4.1 rc and ga.
Bug: CEP-15: (Accord) Invalidation fixes/improvements
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 17/Nov/22 09:52
Resolved: 10/Jan/23 21:21

This patch builds upon the tracker refactor to allow Invalidations to properly track fast path rejections across all contacted shards, and thereby decide whether an invalidation is permissible or recovery should be attempted. This avoids callers being expected to provide unsafe cues around when invalidation may be permissible, and introduces a new mechanism for avoiding infinite invalidate/recovery loops by initiating invalidation on every shard we know of, but proposing the invalidation as soon as we have enough information to safely invalidate any one shard.

This patch also resolves an issue introduced by partial replication, where a transaction adopting a later {{executeAt}} may fail to be properly committed to all shards by the original coordinator, and a transaction that adopted a false dependency on its execution cannot progress because it cannot obtain a full set of dependencies. Since the first transaction now executes after the second, its coordinator does not attempt to ensure progress. This is resolved by introducing a new {{PreCommitted}} status that replicates only the {{executeAt}} without the {{partialDeps}}, so that any shard's (including, most importantly, the home shard's) is sufficient to ensure the progress of any false dependencies.
Bug: Denylist can load perpetually and too frequently if it fails persistently 
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 13/Dec/22 20:19
Resolved: 07/Jan/23 22:01

When the denylist fails its initial load it can [return a value of null|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/schema/PartitionDenylist.java#L453] for a key in the cache. The [BoundedLoadingCache implementation|https://github.com/ben-manes/caffeine/blob/master/caffeine/src/main/java/com/github/benmanes/caffeine/cache/BoundedLocalCache.java#L2591-L2615] that is used treats null as missing and will end up trying to load the key on reads. Besides the performance impact this can also lead to significant log spam leading to disk or CPU usage issues.
Bug: WEBSITE - 4.1 Homepage update and blog post "Apache Cassandra 4.1: Stable, Cloud-Native, Strongly Consistent, and Scale"
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 21/Nov/22 17:38
Resolved: 16/Dec/22 22:49

This ticket is to capture the work associated with publishing the November 2022 homepage update and blog on 4.1.

If this blog cannot be published by the noted publish date on the blog, 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: Adding endpoint verification option to client_encryption_options
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 10/Nov/22 18:28
Resolved: 16/Nov/22 00:07

Add a new property `client_encryption_options.require_endpoint_verification` in cassandra.yaml to enable endpoint verification on client connections optionally. When this property is set to true, the IP/hostname of the client is verified against the IP/hostname that is present in the SAN of the client certificates. This would help in preventing clients stealing certificates from the hosts and using them while connecting to cassandra.
Bug: Add python 3.11 to CI
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 05/Dec/22 15:23
Resolved: 12/Dec/22 15:21

Python 3.11 has a small divergence that necessitates a SaferScanner for that version and those after it in CASSANDRA-18088, similar to what 3.8 did and we solved with CASSANDRA-15573.  We should add 3.11 to our docker images so we can test with it.
Bug: when will slf4j be upgraded for CVE-2018-8088
Status: Resolved
Priority: Normal
Resolution: Not A Problem
Created: 15/Dec/22 21:50
Resolved: 15/Dec/22 21:59

Hello Team,

I see Cassandra 4.1 GA'ed on 12/13/2022 and still uses 1.7.25 version of slf4j and the vulnerability: [https://nvd.nist.gov/vuln/detail/CVE-2018-8088] is fixed only in the 1.7.26 version. Do we have any details on when the slf4j be upgraded ?
Bug: generate.sh -a creates a corrupted yaml file
Status: Open
Priority: Normal
Created: 10/Nov/22 17:45

Tried adding a new build (j11 simulator) and generate.sh -a is success, but it corrupts the yaml with garbage

{code}
$ ./generate.sh -a
Generating new config.yml file with low resources and LOWRES/MIDRES/HIGHRES templates from config-2_1.yml
patching file ./config-2_1.yml
Hunk #4 succeeded at 1520 (offset 18 lines).
Hunk #5 succeeded at 1534 (offset 18 lines).
Hunk #6 succeeded at 1549 (offset 18 lines).
Hunk #7 succeeded at 1563 (offset 18 lines).
Hunk #8 succeeded at 1578 (offset 18 lines).
Hunk #9 succeeded at 1592 (offset 18 lines).
Hunk #10 succeeded at 1607 (offset 18 lines).
Hunk #11 succeeded at 1625 (offset 18 lines).
Hunk #12 succeeded at 1640 (offset 18 lines).
Hunk #13 succeeded at 1658 (offset 18 lines).
Hunk #14 succeeded at 1673 (offset 18 lines).
Hunk #15 succeeded at 1691 (offset 18 lines).
Hunk #16 succeeded at 1706 (offset 18 lines).
patching file ./config-2_1.yml
{code}

{code}
$ head -n 20 .circleci/config.yml.HIGHRES | grep -v '^#'

Error checking for updates: failed to check for updates. `brew outdated --json=v2` returned an error: exit status 1
Please contact support.
{code}
Bug: Allow different compaction strategies per-DC
Status: Triage Needed
Priority: Normal
Created: 08/Dec/22 10:29

I have a requirement for deploying an additional DC. The cluster is split between multiple DCS - on-prem and a cloud.

Several tables use LCS and perform fine on bare metal and not so well on the infrastructure allocated for the cloud DC.

The cloud deployment is intended to run offline analytical batch-type workloads where the criticality of read response times does not necessitate LCS. The cost of presenting appropriate storage for LCS is high and unnecessary for the system requirements or budget.

The JMX call to change compaction locally for testing/migrating compaction, unfortunately, does not survive restarts, schema changes etc.

It would be very helpful to indicate on the table what compaction strategy to use per dc or make the JMX change durable.
Bug: Make snapshot directory configurable
Status: Triage Needed
Priority: Normal
Created: 10/Nov/22 16:59

Currently the snapshot directory is hard-coded to \{table_dir}/snapshots/\{tag}.

It should be possible to configure this to another directory, something like \{snapshot_dir}/\{table}/\{snapshot_tag}.

Alternatively we could make a single directory for all snapshots making the global snapshot tag unique: \{snapshot_dir}/\{global_snapshot_tag}.

We should probably check that \{snapshot_dir} is in the same disk as \{storage_directory} to allow hard linking.
Bug: `generatetokens` uses the wrong allocation strategy
Status: Triage Needed
Priority: Normal
Created: 05/Dec/22 14:52

When the number of racks is the same as the replication factor, token allocation should use `NoReplicationTokenAllocator`. Because `generatetokens` caches the allocation strategy [here|https://github.com/apache/cassandra/commit/2346ed8241022882e77433e283ab8ce3004d12b0#diff-a93e5fa817f4b6d64484e0c28391b76e1760f51860de7f4f036470766ff5090cR225], it uses one that was created before all the racks are defined and does not switch to the correct one.

This has the effect of constructing very poor allocations for the racks = RF case, especially for the first couple of nodes per rack.
Bug: CVE's in Cassandra 4.0.7
Status: Resolved
Priority: Normal
Resolution: Duplicate
Created: 30/Nov/22 11:45
Resolved: 30/Nov/22 15:24

Below CVE's are available in Latest Cassandra version.

CVE-2022-42004,CVE-2022-25857,CVE-2020-11612,CVE-2022-42003

Above CVE's are part of component maven:org.yaml:snakeyaml, maven:io.netty:netty-all, maven:com.fasterxml.jackson.core:jackson-databind
Bug: BLOG - Summit 2023 registrations open
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 30/Nov/22 00:32
Resolved: 30/Nov/22 10:30

Announcing registrations open for the 2023 Apache Cassandra Summit.

Blog draft - https://docs.google.com/document/d/1eX_4bu0DnQ_henIxN0BRQ_2R4j5xADlAkGYGozsGB-Q/edit
Bug: BLOG - BigDATAwire Open Source Projects to Watch Award
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 28/Nov/22 20:54
Resolved: 29/Nov/22 13:07

[~Calico]: "We've discovered that Apache Cassandra has won an Open Source Project to Watch award from BigDATAwire (formerly Datanami)! I've put together a quick post to go on the blog tomorrow."

https://docs.google.com/document/d/1RzKm8HaD0jVZRIK8IZkFfmr9MgPVi0DK3E8Oz8c2M4Q/edit

 !BigDATAwire-2022-award.jpg|width=300!
Bug: Add CQL cast functions for collections
Status: Triage Needed
Priority: Normal
Created: 25/Nov/22 12:20

We have cast functions allowing to upcast numeric data types to bigger values. That is particularly useful for aggregation functions such as {{{}sum{}}}, that might overflow or loss precision if the return type has the same type as the aggregated values:
{code:java}
CREATE TABLE t (k int PRIMARY KEY, v int);
SELECT sum(cast(v AS varint)) FROM t;
SELECT avg(cast(v AS float)) FROM t;
{code}
CASSANDRA-18060 adds new CQL functions analogous to aggregate the elements of a collection, row per row. In order to be able to do the same type of casting, we should have the ability to cast collection values. For example:
{code:java}
CREATE TABLE t (k int PRIMARY KEY, v list<int>);
SELECT collection_sum(cast(v AS list<varint>)) FROM t;
SELECT collection_avg(cast(v AS list<float>)) FROM t;
{code}
Bug: AVG CQL function of an empty set of values returns zero
Status: Triage Needed
Priority: Normal
Created: 25/Nov/22 11:48

The CQL native aggregate function {{avg}} returns zero when it's applied to an empty set of values:
{code:java}
> CREATE TABLE t (k int PRIMARY KEY, v int);
> SELECT avg(v) FROM t;

 system.avg(v)
---------------
             0
{code}
The new {{collection_avg}} that has just been added by CASSANDRA-18060 is based on the {{avg}} implementation, so both are consistent. Thus, it will also return zero for an empty collection:
{code:java}
> CREATE TABLE t (k int PRIMARY KEY, v frozen<set<int>>);
> INSERT INTO t (k,v) VALUES(1, {});
> SELECT collection_avg(v) FROM t;

 system.collection_avg(v)
--------------------------
                        0
{code}
I think these functions should probably better return {{NaN}} instead of zero.

However, returning zero is not terribly incorrect, and returning {{NaN}} might be problematic for backward compatibility.

Also, to further complicate things, {{BigInteger}} and {{BigDecimal}} don't have a {{NaN}} value, so {{avg}} for {{varint}} and {{decimal}} should have a different behaviour, such as:
 * Keep returning zero
 * Return {{null}}
 * Throw an exception
Bug: Website downloads section should explain the noboolean repo
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 17/Nov/22 15:21
Resolved: 18/Nov/22 15:33

After CASSANDRA-17765, there are two different repositories for Redhat-based distros, depending on the distro's ability to understand simple boolean logic.  Currently we have no mention of the noboolean repo, causing users to attempt to install the wrong package.
Bug: Add configurable contact info to user-facing error messages
Status: Triage Needed
Priority: Normal
Created: 16/Nov/22 13:13

It has been mentioned on CASSANDRA-17967 that we could add custom, configurable messages at the end of user-facing messages. That way we could add contact info or particular ways to get support. 

For example, quoting [~jmckenzie] , messages could be:
{quote}
Feature X is disabled because it causes problems Y. Email <group@domain.com> with your cluster name and use-case if you would like to apply for a specific exception
{quote}
There could be a property in {{cassandra.yaml}} containing the common fragment of text to be appended to error messages.