av9ash/GitBugs huggingface dataset:
Bug: Memtable configs don't have defaults for each format supported
Status: Resolved
Priority: Normal
Resolution: Won't Fix
Created: 20/Aug/24 16:28
Resolved: 20/Aug/24 18:48

We added support to change memtable and sstables via yaml but it seems we only added defaults for sstables and missed them for memtables.  We document recommended defaults in config/cassandra.yaml but that isn’t present in Config nor is it present in the resolution logic that translates the config to our maps, this means that anyone who defines their own yaml won’t have “skiplist”, “trie”, or “shardedskiplist” as default options to pick from and must know how to define them.

To make it easier for users we should provide defaults that could be overridden by users, just like we did for SSTables
Bug: Use default commitlog settings in test YAMLs
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 12/Aug/24 20:13
Resolved: 15/Aug/24 16:30

Since nearly the beginning of the project, we've used {{commitlog_sync: batch}} in our test configurations. However, the default is periodic/10s. At a very high level, it seems like we should test the default configuration, and that might be enough of a reason to change this. In addition, we might get a bit of a reduction in testing duration out of the change, especially on older hardware.
Bug: [Analytics] Add job_timeout_seconds writer option
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 12/Aug/24 16:07
Resolved: 14/Aug/24 20:10

Option to specify the timeout in seconds for bulk write jobs. By default, it is disabled.
When JOB_TIMEOUT_SECONDS is specified, a job exceeding the timeout is:
- successful when the desired consistency level is met
- a failure otherwise
Bug: Batchlog and hint replay have timestamps replaced by Accord
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 01/Jul/24 15:51
Resolved: 14/Aug/24 17:16

The issue is that we might create the transaction at a much later time and then the operation would be written to Cassandra with a later timestamp. It should be fine to use the minimum of the two.

This also means that `USING TIMESTAMP` will also work as long as the provided timestamp is < the Accord timestamp.
Bug: Deprecate and ignore use_deterministic_table_id
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 31/Jul/24 16:52
Resolved: 31/Jul/24 21:34

With transactional metadata finally in place in 5.x, we have no further need for {{{}use_deterministic_table_id{}}}. I propose we...

 
1.) Leave CQL {{WITH id}} intact.
2.) Deprecate and WARN on {{use_deterministic_table_id}} ** in 5.0.x.
3.) Ignore and WARN on {{use_deterministic_table_id}} ** in 5.1.
4.) In some future major release, remove {{use_deterministic_table_id}} from {{Config}}
Bug: Revise support for operators in the SAI docs
Status: Open
Priority: Normal
Created: 12/Aug/24 19:32

https://cassandra.apache.org/doc/latest/cassandra/getting-started/sai-quickstart.html#try-out-cql-queries
We do not support OR yet, I do not think we support IN, too. 
We need to double-check the docs as this will be very disappointing experience for users expecting we support certain operators when in reality we don't...yet.
Bug: Minor improvements in Cassandra shutdown and startup logs
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 07/Aug/24 19:31
Resolved: 12/Aug/24 09:40

To improve a DBA experience the following log messages would be nice to add/adjust:
 * on shutdown: an explicit message at the end of Cassandra shutdown
 * on startup:
 ** print the time spent to load prepared statements
 ** print the time spent to load repair session information and the number of loaded session records
 ** print the time spent to apply commit log

It would help with assessment of possible delays in startup/shutdown of Cassandra. For example, recently I observed a delay in Cassandra startup and from logs it was not clear was it caused by loading of prepared statements or repair service init.
Bug: Prevent double closing SSTable writer
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 09/Aug/24 00:29
Resolved: 09/Aug/24 22:49

Analytics uses `org.apache.cassandra.io.sstable.SSTableSimpleWriter` to produce SSTables. Its implementation allows to be closed multiple times. However, the subsequent calls to "close" cause exception. For example,


{code:java}
java.lang.RuntimeException: Last written key DecoratedKey(-3078932293011064831, 000022fd) >= current key DecoratedKey(-3078932293011064831, 000022fd) writing into nb-1-big-Data.db
    	at org.apache.cassandra.io.sstable.format.big.BigTableWriter.beforeAppend(BigTableWriter.java:169)
    	at org.apache.cassandra.io.sstable.format.big.BigTableWriter.append(BigTableWriter.java:208)
    	at org.apache.cassandra.io.sstable.SimpleSSTableMultiWriter.append(SimpleSSTableMultiWriter.java:48)
    	at org.apache.cassandra.io.sstable.SSTableTxnWriter.append(SSTableTxnWriter.java:57)
    	at org.apache.cassandra.io.sstable.SSTableSimpleWriter.writePartition(SSTableSimpleWriter.java:152)
    	at org.apache.cassandra.io.sstable.SSTableSimpleWriter.writeLastPartitionUpdate(SSTableSimpleWriter.java:125)
    	at org.apache.cassandra.io.sstable.SSTableSimpleWriter.close(SSTableSimpleWriter.java:93)
    	at org.apache.cassandra.io.sstable.CQLSSTableWriter.close(CQLSSTableWriter.java:337)
{code}


Cassandra analytics should prevent double closing the underlying writer.
Bug: Fix tests extending FuzzTestBase when running test-compression profile
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 08/Aug/24 18:27
Resolved: 09/Aug/24 12:32

FuzzTestBase extends CQLTester.InMemory which uses jimfs filesystem instead of the real one. This does not play well with direct mode of commitlog_disk_access_mode. We fixed  this in CASSANDRA-19779 by always setting it to mmap. This does not work when we run tests in test-compression profile because then it expects "standard" mode and if fails on asserts.

The solution to fix test-compression profile is to set commitlog_disk_access_mode to mmap only in case it was indeed resolved to direct and not every time.
Bug: Accord: CommandsForKey should self-prune
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 08/Jul/24 15:39
Resolved: 09/Aug/24 11:29

CommandsForKey should periodically self-prune, so as to continue functioning well in-between garbage collections. This is a bit complicated, as once we prune we are left with potentially incomplete information, and have to sometimes load per-command information from disk. But the payoff is ensuring CommandsForKey objects - which drive the majority of the state machine - are kept to a reasonable size.
Bug: direct IO support is always evaluated to false upon the very first start of a node
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 18/Jul/24 12:53
Resolved: 05/Aug/24 00:14

When I extract the distribution tarball and I want to use tools in tools/bin, there is this warn log visible every time for tools when they are started (does not happen on "help" command, obviously)
{code:java}
WARN  14:25:11,835 Unable to determine block size for commit log directory: null {code}
This is because we introduced this (1) in CASSANDRA-18464

What that does is that it will go and try to create a temporary file in commit log directory to get "block size" for a "file store" that file is in.

The problem with that is that when we just extract a tarball and run the tools - Cassandra was never started - then such commit log directory does not exist yet, so it tries to create a temporary file in a non-existing directory, which fails, hence the log message.

The fix is to check if commitlog dir exists and return / skip the resolution of block size if it does not.

Another approach might be to check if this is executed in the context of a tool and skip it from resolution altogether. The problem with this is that not all tools we have in bin/log call DatabaseDescriptor.
toolInitialization() so we might combine these two.
(1) [https://github.com/apache/cassandra/blob/cassandra-5.0/src/java/org/apache/cassandra/config/DatabaseDescriptor.java#L1455-L1462]
Bug: Cassandra 4.1.5 on RedHat repo is no longer available and only version 4.1~alpha1-1 is available
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 08/Aug/24 15:40
Resolved: 08/Aug/24 22:11

It looks like some configuration of the rpm repository for Cassandra 41x has changed and means only version 4.1~alpha1-1 is available.

We're trying to build a Docker image using Cassandra 4.1.5 version and a few days back the build was working as expected. 2-3 days ago the build is now failing and it no longer works. Here's the error message:
{code:java}
No package cassandra-4.1.5-1 available. {code}
Inspecting the repository [https://apache.jfrog.io/ui/native/cassandra-rpm/41x/] I can see that version 4.1.5 is listed, but it is not returned when executing yum search / yum list:
{code:java}
$ yum list cassandra --showduplicates
Available Packages
cassandra.noarch 4.1~alpha1-1
cassandra cassandra.src 4.1~alpha1-1 cassandra{code}
A series of files were modified on 2024-08-03 (five days ago) in the directory [https://apache.jfrog.io/ui/native/cassandra-rpm/41x/repodata] - could this be the change that caused this behaviour? We are now unable to install any version of Cassandra 4.1.x except the alpha release.
{code:java}
 $ cat /etc/yum.repos.d/cassandra.repo
[cassandra]
baseurl = https://redhat.cassandra.apache.org/41x/ 
enabled = 1 
gpgcheck = 1 
gpgkey = https://downloads.apache.org/cassandra/KEYS 
name = Apache Cassandra
repo_gpgcheck = 1
{code}
Bug: [Analytics] Stream sstable eagerly when bulk writing to allow reclaiming local disk space
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 29/Jul/24 21:29
Resolved: 08/Aug/24 00:03

Currently, each bulk write executor only sends sstables after exhausting the input data (of the task). All produced sstables are staged locally, when executor local disk space is limited or the input data size is too large, there is a risk of running out of disk space.
The patch changes the streaming strategy to stream eagerly and remove the local files sooner.
Bug: PasswordAuthenticator accepts passwords with matching prefixes exceeding bcrypt length limit
Status: Triage Needed
Priority: Normal
Created: 07/Aug/24 15:35

Cassandra allows roles to be created with passwords longer than the bcrypt length limit of 72 bytes[1]. All passwords sharing a 72-byte prefix have the same bcrypt hash, so users can authenticate with passwords that do not exactly match a role's configured password.
 
Users expect authentication to only happen when there is an exact match between a role's configured password and the password provided by an agent authenticating against that role.

I have a few elements to propose:
1. Cassandra rejects creation of passwords (via CREATE ROLE or ALTER ROLE) that exceed the 72-byte limit
2. Cassandra logs a server-side warning (not ClientWarn) when a role's password exceeds the length limit, recommending a password change, with NoSpamLogger

Thanks to Stefan Miklosovic for investigating this with me.

As for proof, here's a failing test:
{code:java}
import org.mindrot.jbcrypt.BCrypt;
public class PasswordCollisionTest
{
   @Test
   public void testLongPassword() throws Exception
   
{        String longpassword = "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa";        String salt = BCrypt.gensalt();        String longhashed = BCrypt.hashpw(longpassword, salt);        Assert.assertTrue(BCrypt.checkpw(longpassword, longhashed));        String longerpassword = longpassword + "bbb";        String longerhashed = BCrypt.hashpw(longerpassword, salt);        Assert.assertNotEquals(longerhashed, longhashed);    }
}
{code}
 

Here's a similar test as an end-user would experience it, against recent trunk (fe30e227bdedf13f890e242d2646598398ba8bed):
{code:java}
$ ./bin/cqlsh -u cassandra -p cassandra
Connected to Test Cluster at 127.0.0.1:9042
[cqlsh 6.0.0 | Cassandra 5.1-SNAPSHOT | CQL spec 3.4.8 | Native protocol v5] 
Use HELP for help.
cassandra@cqlsh> CREATE ROLE longpassword WITH PASSWORD = 'aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa' AND LOGIN = true;
cassandra@cqlsh> exit;
$ ./bin/cqlsh -u longpassword -p aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
Connected to Test Cluster at 127.0.0.1:9042
[cqlsh 6.0.0 | Cassandra 5.1-SNAPSHOT | CQL spec 3.4.8 | Native protocol v5] 
Use HELP for help.
longpassword@cqlsh> exit;
$ ./bin/cqlsh -u longpassword -p aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaabbb
Connected to Test Cluster at 127.0.0.1:9042
[cqlsh 6.0.0 | Cassandra 5.1-SNAPSHOT | CQL spec 3.4.8 | Native protocol v5] 
Use HELP for help.
longpassword@cqlsh> exit;
{code}
 

[1]: [https://en.wikipedia.org/wiki/Bcrypt#Maximum_password_length]
Bug: timeout on  upgrade_tests/upgrade_through_versions_test.py::TestProtoV3Upgrade_AllVersions_RandomPartitioner_EndsAt_Trunk_HEAD::test_parallel_upgrade
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 02/Aug/24 10:07
Resolved: 07/Aug/24 09:33

 The upgrade_tests/upgrade_through_versions_test.py::TestProtoV3Upgrade_AllVersions_RandomPartitioner_EndsAt_Trunk_HEAD::test_parallel_upgrade  test is taking longer than usual.

CI in 5.0 is timing out the dtest-upgrade-large 59/64 split always now.

Our 5.0-rc testing results are tainted because these time outs always abort the 5.0 pipeline runs.

It looks like that split is taking 16x times as long now… 

This appears to be caused from either/both
- https://github.com/apache/cassandra/commit/08e1fecf36507397cf3122d77f84aa23150da588
- https://github.com/apache/cassandra-dtest/commit/2b17c1293056068bb3e94c332d6fb99df6a0b0fa


Example of good run.
 [^test_rolling_upgrade.257.good.log] (ci-cassandra.a.o)

Examples of bad runs.
 [^test_rolling_upgrade.122.log],  [^test_rolling_upgrade.123-2.log],  [^test_rolling_upgrade.123-1.log],  [^test_rolling_upgrade.134.log]  (internal ci)
 [^test_rolling_upgrade.261-1.log] ,  [^test_rolling_upgrade.261-2.log]  (ci-cassandra.a.o)
Bug: Flakey test org.apache.cassandra.distributed.test.TransientRangeMovement2Test#testMoveForward
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 26/Jul/24 17:41
Resolved: 07/Aug/24 07:45

{code}
 junit.framework.AssertionFailedError: SHOULD NOT BE ON NODE: 11 -- [(16,30)]: [00, 02, 04, 06, 08, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 42, 44, 46, 48]
	at org.apache.cassandra.distributed.test.TransientRangeMovementTest.assertAllContained(TransientRangeMovementTest.java:231)
	at org.apache.cassandra.distributed.test.TransientRangeMovement2Test.testMoveForward(TransientRangeMovement2Test.java:143)
{code}
Bug: Flakey test upgrade_tests.upgrade_through_versions_test.TestProtoV3Upgrade_AllVersions_EndsAt_Trunk_HEAD#test_rolling_upgrade
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 26/Jul/24 17:44
Resolved: 02/Aug/24 07:02

{code}
==================================== ERRORS ====================================
_ ERROR at teardown of TestProtoV3Upgrade_AllVersions_EndsAt_Trunk_HEAD.test_rolling_upgrade _
Unexpected error found in node logs (see stdout for full details). Errors: [[node3] 'ERROR [InternalResponseStage:3] 2024-07-26 04:35:12,345 MessagingService.java:509 - Cannot send the message (from:/127.0.0.3:7000, type:FETCH_LOG verb:TCM_FETCH_PEER_LOG_REQ) to /127.0.0.1:7000, as messaging service is shutting down', [node3] 'ERROR [InternalResponseStage:4] 2024-07-26 04:35:27,412 MessagingService.java:509 - Cannot send the message (from:/127.0.0.3:7000, type:FETCH_LOG verb:TCM_FETCH_PEER_LOG_REQ) to /127.0.0.1:7000, as messaging service is shutting down']
{code}
Bug: Gossiper (micro) optmizations
Status: Resolved
Priority: Normal
Resolution: Won't Fix
Created: 31/Jul/24 03:03
Resolved: 31/Jul/24 10:38

I am wondering about optimizations that can be done in the gossiper class, especially targeting performance at larger scales. 
 # getLiveMembers: Creating a hashmap every time this is called. Aside from creating some trash, its linear in terms of the number of peers.
 # getMaxEndpointStateVersion: I feel this can be calculated and cached rather than looking for it. It is also linear on the number of peers.
 # getGossipStatus: Linear in the number of peers, also source of garbage at larger scales.

It seems optmizing these methods can contribute to a cleaner/performant membership protocol. Is there any plans on having these types of optmizations?
Bug: Harry Simulation test halts the JVM when errors are detected which loose all history in CI
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 25/Jul/24 17:27
Resolved: 25/Jul/24 22:08

The Harry simulation test has a few issues, but the biggest is it calls System.exit when an error is found… this blocks the JVM from creating a test report and can loose all history needed to reproduce the issue..

1) when the test fails it doesn’t properly show the seed
2) you can’t rerun the test with the same seed without modifying the code
3) if uncaught exceptions are found the test still passes (this is masking TCM issues)
Bug: CEP-15 (Accord): When starting a transaction in a table where Accord is not enabled, should fail fast rather than fail with lack of ranges
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 08/Jul/24 17:23
Resolved: 23/Jul/24 21:32

Reported in Slack: https://the-asf.slack.com/archives/C0459N9R5C6/p1712831271287869

The “accord_demo.txt” has the following

{code}
ccm create accord-cql-poc -n 3
ccm start

bin/cqlsh -e "create keyspace ks with replication={'class':'SimpleStrategy', 'replication_factor':3};"
bin/cqlsh -e "create table ks.tbl1 (k int primary key, v int);"
bin/cqlsh -e "create table ks.tbl2 (k int primary key, v int);"

bin/nodetool -h 0000:0000:0000:0000:0000:ffff:7f00:0001 -p 7100 createepochunsafe
bin/nodetool -h 0000:0000:0000:0000:0000:ffff:7f00:0001 -p 7200 createepochunsafe
bin/nodetool -h 0000:0000:0000:0000:0000:ffff:7f00:0001 -p 7300 createepochunsafe

BEGIN TRANSACTION
  LET row1 = (SELECT * FROM ks.tbl1 WHERE k = 1);
  SELECT row1.v;
  IF row1 IS NULL THEN
    INSERT INTO ks.tbl1 (k, v) VALUES (1, 2);
  END IF
COMMIT TRANSACTION;
{code}

If you run that it fails in an unclear way

{code}
cqlsh> BEGIN TRANSACTION
   ...   LET row1 = (SELECT * FROM ks.tbl1 WHERE k = 1);
   ...   SELECT row1.v;
   ...   IF row1 IS NULL THEN
   ...     INSERT INTO ks.tbl1 (k, v) VALUES (1, 2);
   ...   END IF
   ... COMMIT TRANSACTION;
NoHostAvailable: ('Unable to complete the operation against any hosts', {<Host: 127.0.0.1:9042 datacenter1>: <Error from server: code=0000 [Server error] message="java.lang.IllegalStateException: Unable to select a HomeKey as the topology does not have any ranges for epoch 17">})
{code}

The issue is that the table was not marked as an Accord table; aka missing 

{code}
WITH transactional_mode='full'
{code}

The demo should be updated to show this, but the error message should also be improved.  We validate that the table exists but now that the metadata is required we should also enforce this in CQL validation
Bug: Allow configuring log format for Audit Logs
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 22/Jul/24 17:52
Resolved: 24/Jul/24 22:04

Enhance the configuration for audit loggers to take two new parameters. One is for defining the key-value separator character, and the second is for the field separator character.

The existing behavior will be preserved. However an operator can configure parameters to customize the separators. For example:


{code:java}
audit_logging_options:
  enabled: false
  logger:
    - class_name: FileAuditLogger
      parameters:
        - key_value_separator: "="
          field_separator: " "
{code}
Bug: In SAI, intersecting two indexes doesn't require ALLOW FILTERING
Status: Triage Needed
Priority: Normal
Created: 24/Jul/24 12:37

As explained many years ago in https://issues.apache.org/jira/browse/CASSANDRA-5470, when a query involves intersecting two secondary indexes, e.g., "WHERE x=1 AND y=2" where "x" and "y" are two indexed column, ALLOW FILTERING is required.

I verified that this is still the case today, in Cassandra 5.0-rc1.

But if you use SAI instead of the classic secondary index, suddenly ALLOW FILTERING is not required.

I think this is a regression. Even if SAI has a more efficient way of intersecting the posting list from two indexes (does it?), in the worst case this doesn't help: For example, consider a table with a million rows, half have x=1 and the other half have y=2 and just one row has both. Now, a query for "WHERE x=1 AND y=2" needs to process half a million rows just to produce one result. This is ALLOW FILTERING par excellence.
Bug: Remove centos7 (and use vault mirror for ant-junit rpm download)
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 22/Jul/24 11:28
Resolved: 22/Jul/24 18:14

centos7 is EOL, and its rpm repository is gone.

Use almalinux for the noboolean builds, and use the redhat vault repository to get the ant-junit rpm.
Bug: Scrubber can't fix corrupted compressed sstable and generate corrupted sstable
Status: Triage Needed
Priority: Normal
Created: 20/Jul/24 01:08

When scrubber detects a corruption, `CompressedSequentilWriter#resetAndTruncate` will be called:
* `uncompressedSize` and `compressedSize` are not reset. When flushing next chunk, last flush offset will be computed based on wrong size. We should get rid of these variables and compute `lastFlushOffset` directly based on `uncompressedLength`
*  CRC value is computed from flushed chunks which may have been reset, but we can't reset digest value to previous file offset. The final digest value will be wrong. We have to rescan data file at the end of writer to compute proper digest if resetAndTruncate is called.

Reproduction -[unit test|https://github.com/jasonstack/cassandra/commit/106e9460f7e6e9690aa056def5329174bbca9a47] (not sure why the test didn't work on trunk due to buffer already released): 
* populate multiple large partitions
* corrupt middle of the file
* The point is to have partition size much larger than the compression chunk size. When `resetAndTruncate` is called (corruption found), some chunks for the partition have been flushed and will be reset.
Bug: Update doc page for how-to commit with more intro
Status: Triage Needed
Priority: Normal
Created: 17/Jul/24 15:22

The how-to commit documentation would be more helpful to new committers with some background details on the below.  This should not be a git tutorial, but it should inform readers what they need to know or learn to be an effective committer.

0a) Using CLI vs GitHub web UI
0b) Always do your work in a local branch, and never push a branch upsteam.

1) The squash-rebase-merge (best name?) workflow with feature branches used on this repo

2) Basic git commands you should know, including:
* *git remote* add & set-url
* *squashing* with rebase -i
* updating commit with *git commit --amend*
* *push upstream <repo> --atomic -n*
Bug: Coordinator read latency metrics are inflated for some queries
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 05/Jul/24 17:26
Resolved: 10/Jul/24 08:30

When a partition read is decomposed on the coordinator into multiple single partition read queries, the latency metric captured in StorageProxy can be artificially increased.
This primarily affects reads where paging and aggregates are used or where an IN clause selects multiple partition keys.