av9ash/GitBugs huggingface dataset:
Bug: [Analytics] Deprecate option SIDECAR_INSTANCES and replace with SIDECAR_CONTACT_POINTS
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 13/Jul/24 20:51
Resolved: 17/Jul/24 04:44

This patch introduces a new option SIDECAR_CONTACT_POINTS for both bulk writer and reader. The option name better describes the purpose, which is to specify the initial contact points to discover the cluster topology. The existing option SIDECAR_INSTANCES are used for the same purpose and it is not deprecated.
In addition, it allows including the port value in the addresses when defining SIDECAR_CONTACT_POINTS
Bug: [Analytics] Bump Cassandra Sidecar version to fix build issue
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 16/Jul/24 21:31
Resolved: 16/Jul/24 22:21

Cassandra analytics build is failing due to sidecar build failure. It is fixed in the latest Cassandra Sidecar. This patch bumps the sidecar version in analytics.
Bug: Fix storage_compatibility_mode and startup_checks documentation
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 11/Jul/24 23:01
Resolved: 15/Jul/24 16:17

The documentation for storage_compatibility_mode ([https://cassandra.apache.org/doc/latest/cassandra/managing/configuration/cass_yaml_file.html#storage_compatibility_mode]) is very difficult to read. The below highlighted text seems incorrect.

!image-2024-07-12-09-38-16-284.png|width=505,height=487!

 

It appears that the entry for the YAML option above it is causing entries to get clobbered together (startup_checks)

 

This is actually a very useful and important feature for people upgrading to Cassandra 5 to understand how to use properly - It would be good for it to be easier to read, we should be encouraging use of the safest possible upgrade path, which from my understanding would be:

{{CASSANDRA_4 -> UPGRADING -> NONE}}

 

 

Update - seems like the startup_checks docs is also missing in the 4.1 pages, I'll fix that as well.
Bug: Corruption can occur while a field is being added to UDT clustering key
Status: Triage Needed
Priority: Normal
Created: 11/Jul/24 14:52

CASSANDRA-15938 made some improvements in how unknown components in UDTs are treated. Unfortunately this can cause corruption as soon as more than one value is inserted for a partition.

The problem can be easily shown by modifying the {{FrozenUDTTest.testDivergentSchema}} test to insert two entries in the wrong order:
{code:java}
cluster.coordinator(1).execute("insert into " + KEYSPACE + ".x (id, ck, i) VALUES (?, " + json(1, 2) + ", ? )", ConsistencyLevel.ALL,
1, 2);
cluster.coordinator(1).execute("insert into " + KEYSPACE + ".x (id, ck, i) VALUES (?, " + json(1, 1) + ", ? )", ConsistencyLevel.ALL,
1, 1);
{code}
after which we can get corrupted sstable state, shown as a
{code:java}
java.lang.AssertionError: Lower bound [SSTABLE_LOWER_BOUND(1) ]is bigger than first returned value [Row: ck=1 | i=2]
{code}
exception, or results like {{[[1],[2],[2],[1]]}} or {{[[2],[1],[2]]}} for {{select i from x WHERE id = 1}} depending on which node we use as coordinator.

Because we don't know the type of new fields and cannot properly order entries, we need to outright reject UDT keys that are not compatible with a replica's schema.
Bug: Incorrect latency metrics reported by metric-reporter
Status: Open
Priority: Normal
Created: 12/Jul/24 10:00

Cassandra version: 4.1.5

Since [CASSANDRA-16760|https://issues.apache.org/jira/browse/CASSANDRA-16760] and [these changes|https://github.com/apache/cassandra/pull/1091/files#diff-07f330b65d5335967ea96f80674b25415c70994d99b97795ed4db696c92b3ff5L532], the metric reporter is dividing the microseconds metrics by 10^6 and reporting it as  milliseconds unit (it should be divided by 10^3). This means an additional division of 10^3 happens causing the metrics to be wrong.

The sample configuration or documentation does not include how to configure the metrics reporter to report it correctly.

Steps to reproduce:

Contents of metrics-reporter-config-sample.yaml
{noformat}
console:
  -
    outfile: '/tmp/metrics.out'
    period: 10
    timeunit: 'SECONDS'
    predicate:
      color: "white"
      useQualifiedName: true
      patterns:
        - "^org.apache.cassandra.metrics.ClientRequest.+" # includes ClientRequestMetrics
{noformat}

Cassandra started with flag
{noformat}
-Dcassandra.metricsReporterConfigFile=metrics-reporter-config-sample.yaml
{noformat}

Run cassandra-stress to generate load
{noformat}
tools/bin/cassandra-stress write duration=1m cl=ONE -rate threads=1000
{noformat}

Post that
If you check via nodetool
{noformat}
bin/nodetool sjk mxdump -q org.apache.cassandra.metrics:type=ClientRequest,scope=Write-ONE,name=Latency

{
  "beans" : [ {
    "name" : "org.apache.cassandra.metrics:type=ClientRequest,scope=Write-ONE,name=Latency",
    "modelerType" : "org.apache.cassandra.metrics.CassandraMetricsRegistry$JmxTimer",
    "Max" : 654949.0,
    "999thPercentile" : 11864.0,
    "DurationUnit" : "microseconds",
    ....
  } ]
}

{noformat}

The max is 654949.0 micros which  654 millis.

However, the metric reporter emits 0.65 millis because of the division of additional 10^3 factor

{noformat}
❯ tail -n100 /tmp/metrics.out | grep -A 20 Latency.Write-ONE
org.apache.cassandra.metrics.ClientRequest.Latency.Write-ONE
            count = 17053398
            max = 0.65 milliseconds
            99.9% <= 0.01 milliseconds
            ...
{noformat}
Bug: ALTER USER | ROLE IF EXISTS creates a user / role if it does not exist
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 04/Jul/24 11:58
Resolved: 09/Jul/24 15:37

Let's have:

{code}
authenticator:
  class_name : org.apache.cassandra.auth.PasswordAuthenticator
authorizer: CassandraAuthorizer
role_manager: CassandraRoleManager
{code}

and do this:

{code}
cassandra@cqlsh> select * from system_auth.roles;

 role      | can_login | is_superuser | member_of | salted_hash
-----------+-----------+--------------+-----------+--------------------------------------------------------------
 cassandra |      True |         True |      null | $2a$10$sFCKeluid5MlW/Z0CU1ygO1U5qpLW4Rgivmu8rZNmNNQ8WeC2y92S

{code}

Then 

{code}
cassandra@cqlsh> ALTER USER IF EXISTS this_does_not_exist SUPERUSER ;
cassandra@cqlsh> select * from system_auth.roles where role = 'this_does_not_exist';

 role                | can_login | is_superuser | member_of | salted_hash
---------------------+-----------+--------------+-----------+-------------
 this_does_not_exist |      null |         True |      null |        null

{code}

It seems to be same behaviour for ALTER ROLE too.

{code}
cassandra@cqlsh> ALTER ROLE IF EXISTS this_role_is_not_there WITH SUPERUSER = true ;
cassandra@cqlsh> select * from system_auth.roles where role = 'this_role_is_not_there';

 role                   | can_login | is_superuser | member_of | salted_hash
------------------------+-----------+--------------+-----------+-------------
 this_role_is_not_there |      null |         True |      null |        null

{code}
Bug: Invalid schema.cql created by snapshot after dropping more than one field
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 03/Jul/24 09:40
Resolved: 10/Jul/24 09:30

After dropping at least 2 fields the schema.cql produced by _nodetool snapshot_ is invalid (it is missing a comma)
{code:sql}
CREATE TABLE IF NOT EXISTS test.testtable (
    field1 text PRIMARY KEY,
    field2 text
    field3 text
) WITH ID ...{code}
expected outcome
{code:sql}
CREATE TABLE IF NOT EXISTS test.testtable (
    field1 text PRIMARY KEY,
    field2 text,
    field3 text
) WITH ID ...{code}
reproducing the isue is simple by running the following commands
{code:sh}
docker run -d --name cassandra cassandra:4.1.5

echo "Wait for the container to start"
until docker exec -ti cassandra nodetool status | grep UN;do sleep 1;done;sleep 10

echo "Create keyspace and table for test"
docker exec -ti cassandra cqlsh -e "CREATE KEYSPACE IF NOT EXISTS test WITH replication = {'class': 'SimpleStrategy', 'replication_factor': '1'}; CREATE TABLE IF NOT EXISTS test.testtable (field1 text PRIMARY KEY,field2 text,field3 text);"

echo "Drop 2 fields"
docker exec -ti cassandra cqlsh -e "ALTER TABLE test.testtable DROP (field2, field3);"

echo "Create snapshot and view schema.cql"
docker exec -ti cassandra /opt/cassandra/bin/nodetool snapshot -t my_snapshot
docker exec -ti cassandra find /var/lib/cassandra/data -name schema.cql  -exec cat {} +   {code}
the full output of the sql generated by the reproduce is below
{code:sql}
CREATE TABLE IF NOT EXISTS test.testtable (
    field1 text PRIMARY KEY,
    field2 text
    field3 text
) WITH ID = 0e9aa540-391f-11ef-945e-0be1221ff441
    AND additional_write_policy = '99p'
    AND bloom_filter_fp_chance = 0.01
    AND caching = {'keys': 'ALL', 'rows_per_partition': 'NONE'}
    AND cdc = false
    AND comment = ''
    AND compaction = {'class': 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy', 'max_threshold': '32', 'min_threshold': '4'}
    AND compression = {'chunk_length_in_kb': '16', 'class': 'org.apache.cassandra.io.compress.LZ4Compressor'}
    AND memtable = 'default'
    AND crc_check_chance = 1.0
    AND default_time_to_live = 0
    AND extensions = {}
    AND gc_grace_seconds = 864000
    AND max_index_interval = 2048
    AND memtable_flush_period_in_ms = 0
    AND min_index_interval = 128
    AND read_repair = 'BLOCKING'
    AND speculative_retry = '99p';
ALTER TABLE test.testtable DROP field2 USING TIMESTAMP 1719999102807000;
ALTER TABLE test.testtable DROP field3 USING TIMESTAMP 1719999102807001;
{code}

Found this bug while trying to restore the schema from a backup  created by copying a snapshot from a running node.
Bug: Not getting responses with concurrent stream IDs in native protocol v5
Status: Resolved
Priority: Normal
Resolution: Not A Problem
Created: 05/Jul/24 12:16
Resolved: 10/Jul/24 09:40

This is not gonna be an easy bug to report or to give a great set of repro steps for, so apologies in advance. I’m one of the authors and the maintainer of [Xandra|https://github.com/whatyouhide/xandra], the Cassandra client for Elixir.

We noticed an issue with request timeouts in a new version of our client. Just for reference, the issue is [this one|https://github.com/whatyouhide/xandra/issues/356].

After some debugging, we figured out that the issue was limited to *native protocol v5*. With native protocol v5, the issue shows up in C* 4.1 and 5.0. With native protocol v4, those versions (4.1 and 5.0) both work fine. I'm running C* in a Docker container, but I've had folks reproduce this with all sorts of C* setups.

h2. The Issue

The new version of our client in question uses concurrent requests. We assign each request a sequential stream ID ({{1}}, {{2}}, ...). We behave in a compliant way with [section 2.4.1.3. of the native protocol v5 spec|https://github.com/apache/cassandra/blob/e7cf38b5de6f804ce121e7a676576135db0c4bb1/doc/native_protocol_v5.spec#L316C1-L316C9]—to the best of my knowledge.

Now, it seems like C* does not respond do all requests this way. We have a [simple test|https://github.com/whatyouhide/xandra/pull/368] in our repo that reproduces this. It just issues two requests in parallel (with stream IDs {{1}} and {{2}}) and then keeps issuing requests as soon as there are responses. Almost 100% of the times, we don't get the response on at least one stream. I've also attached some debug logs that show this in case it can be helpful (from the client perspective). The {{<<56, 0, 2, 67, 161, ...>>}} syntax is Erlang's syntax for bytestrings, where each number is the decimal value for a single byte. You can see in the logs that we never get the response frame on stream ID 1. Sometimes it's stream ID 2, or 3, or whatever.

I’m pretty short on what to do next on our end. I’ve tried shuffling around the socket buffer size as well (from {{10}} bytes to {{1000000}} bytes) to get the packets to split up in all sorts of places, but everything works as expected _except_ for the requests that are not coming out of C*.

Any other help is appreciated here, but I've started to suspect this might be something with C*. It could totally not be, but I figured it was worth to post out here.

Thank you all in advance folks! 💟
Bug: Debian packaging fails after openjdk-8* and java8* removed from bullseye
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 05/Jul/24 11:39
Resolved: 05/Jul/24 16:18

No candidates for {{`openjdk-8-jdk | java8-jdk`}}

Failure occurs at the {{mk-build-deps}} step…
{noformat}
Broken cassandra-build-deps:amd64 Depends on openjdk-8-jdk:amd64 < none @un H >
     Removing cassandra-build-deps:amd64 because I can't find openjdk-8-jdk:amd64
Broken cassandra-build-deps:amd64 Depends on java8-jdk:amd64 < none @un H >
     Removing cassandra-build-deps:amd64 because I can't find java8-jdk:amd64
     Or group remove for cassandra-build-deps:amd64
…
mk-build-deps: Unable to install cassandra-build-deps at /usr/bin/mk-build-deps line 457.
mk-build-deps: Unable to install all build-dep packages
{noformat}
ref: https://ci-cassandra.apache.org/job/Cassandra-3.0-artifacts/jdk=jdk_1.8_latest,label=cassandra/428/console
Bug: Update dependency-check library to version 10.0.0
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 01/Jul/24 19:53
Resolved: 01/Jul/24 22:35

Currently, we are at 9.0.5, which gives me locally basically this (1)

Version 10.0.0 was released today and check is passing again.

We should update it everywhere to 10.0.0

(1) https://github.com/jeremylong/DependencyCheck/issues/6515
Bug: Do not fail cqlsh when empty statement is parsed
Status: Patch Available
Priority: Low
Created: 26/Sep/24 13:11

This really irritates me. 
{code:java}
cqlsh> select * from ks.tb;;
... the result ...
SyntaxException: line 1:0 no viable alternative at input ';' ([;]){code}
The second ";" should not matter. It is same way e.g. in Java. When I do
{code:java}
int a = 5;;;;;;;; {code}
This is just perfectly legal. Indeed, more than one ";" is redundant, but it still compiles.

We should do same for CQL.
{code:java}
cqlsh> select * from ks.tb;;;;;;;;; {code}
This should not fail.
Bug: Add / modify pull request template and issue template
Status: Needs Committer
Priority: Low
Created: 22/Aug/24 09:03

Similar to what we did in CASSANDRA-17837 there should be a template for developers of go-cql driver as well which currently looks like this

https://github.com/apache/cassandra/blob/trunk/.github/pull_request_template.md

It should be modified to reflect specifics in go-cql driver whatever they are.
Bug: Improve JVMStabilityInspector error message to clarify off-heap vs heap OOM errors
Status: Open
Priority: Low
Created: 12/Aug/24 21:05

When we see Direct buffer memory errors, the JVMStabilityInspector appears to suggest it's a heap OOM to casual users.  This can confuse users who think that increasing the heap may help solve the problem. A vendors support staff suggested increasing the heap in this scenario.

A more clear error message could be something like:

Off-heap OOM forcing heap space OutOfMemoryError after OutOfMemoryError: Direct buffer memory
{quote}2024-08-01 17:00:00,16 [ERROR] [Messaging-EventLoop-3-6] cluster_id=001 ip_address=172.0.0.1  JVMStabilityInspector.java:151 - Force heap space OutOfMemoryError in the presence of
java.lang.OutOfMemoryError: Direct buffer memory
  at java.base/java.nio.Bits.reserveMemory(Bits.java:175)
  at java.base/java.nio.DirectByteBuffer.<init>(DirectByteBuffer.java:118)
  at java.base/java.nio.ByteBuffer.allocateDirect(ByteBuffer.java:318)
  at org.apache.cassandra.utils.MerkleTree.allocate(MerkleTree.java:742)
  at org.apache.cassandra.utils.MerkleTree.deserializeOffHeap(MerkleTree.java:780)
{quote}
The comment in the code is clear, but 
{quote}  /**
     * Intentionally produce a heap space OOM upon seeing a non heap memory OOM.
     * Direct buffer OOM cannot trigger JVM OOM error related options,
     * e.g. OnOutOfMemoryError, HeapDumpOnOutOfMemoryError, etc.
     * See CASSANDRA-15214 and CASSANDRA-17128 for more details
     */
{quote}
but the log message users see begins with 'Force heap space OutOfMemoryError', which suggests a heap memory issue, not off-heap memory.  Very confusing for general users and junior support staff.
Bug: Update for NOT operator for 5.1 What's new page
Status: Open
Priority: Low
Created: 30/Aug/24 17:04

Below is a short summary of CASSANDRA-18584 that can be added to a What's new in 5.1 page when the time for that page comes.


{code:java}
CQL NOT CONTAINS, NOT CONTAINS KEY, != for map entries
    
    Ability to use NOT operator in filters on lists, sets and maps.
    Requires ALLOW FILTERING.
    
    All those operators can be mixed: i.e. you can use
    multiple CONTAINS, NOT CONTAINS, CONTAINS KEY, NOT CONTAINS KEY
    in a single WHERE clause.
    
    CQL NOT IN operator
    Ability to use NOT IN restrictions in CQL WHERE clause.
    Can be used on any column with ALLOW FILTERING.
    
    Can be also used on clustering columns w/o ALLOW FILTERING.
    Multicolumn NOT IN restrictions are supported
    (e.g. (c1, c2) NOT IN ((1, 2), (3, 4))).
    
    NOT IN restrictions are implemented as slice restrictions, therefore
    they can be merged with other slice restrictions using <, >, <=, >=.
    Also multiple NOT IN restrictions can be merged together.
    
    Allow CQL equals / non-equals operators in more places
    Now that we implemented NOT IN, both equals and non-equals
    can be rewritten as slices.
    
    column != value ---> column NOT IN (value)
    column  = value ---> column >= value AND column <= value
    
    And because slices can be freely merged, this opens room for
    many interesting queries that were previously
    impossible, e.g.:
    
    SELECT ... WHERE c1 != ?
    SELECT ... WHERE c1 != ? AND c1 != ? AND ...
    SELECT ... WHERE c1 = ? AND (c1, c2) != (v1, v2)
    SELECT ... WHERE c1 IN ? AND (c1, c2) != (v1, v2)
    
    We adhere to the Three Valued Logic
{code}

Of course the text can be tweaked but that is the TLDR, leaving it here so it does not get lost.
The CQL docs were updated adding the new operators
Bug: distributed.test.ring.BootstrapTest#bootstrapUnspecifiedResumeTest fails sometimes
Status: Triage Needed
Priority: Low
Created: 29/Aug/24 16:26

org.apache.cassandra.distributed.test.ring.BootstrapTest#bootstrapUnspecifiedResumeTest JUnit test may fail rarely with NPE:
{code:java}
 java.lang.NullPointerException: Cannot invoke "org.apache.cassandra.gms.EndpointState.getApplicationState(org.apache.cassandra.gms.ApplicationState)" because "state" is null

	at org.apache.cassandra.distributed.action.GossipHelper$PullSchemaFrom.lambda$accept$6adea493$1(GossipHelper.java:245)
	at org.apache.cassandra.distributed.impl.IsolatedExecutor.lambda$async$10(IsolatedExecutor.java:156)
	at org.apache.cassandra.concurrent.FutureTask$2.call(FutureTask.java:124)
	at org.apache.cassandra.concurrent.FutureTask.call(FutureTask.java:61)
	at org.apache.cassandra.concurrent.FutureTask.run(FutureTask.java:71)
	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
	at io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
	at java.base/java.lang.Thread.run(Thread.java:840){code}
Observed during testing of CASSANDRA-19651
It is not reproduced easily.
As a part of Instance.startup org.apache.cassandra.gms.Gossiper#waitToSettle waits for 5 +3 x 1 = 8 seconds if there are no changes in the number of nodes discovered using gossip (even if we have not had any interactions with other nodes using gossip at all).
I have added a 5-second sleep to org.apache.cassandra.gms.Gossiper.GossipTask#run (we also have 1 second of initial delay when we schedule GossipTask)
{code:java}
 private class GossipTask implements Runnable
    {
        public void run()
        {
            try
            {
                //wait on messaging service to start listening
                MessagingService.instance().waitUntilListening();
                Thread.sleep(5000); // <===============================

                taskLock.lock();
{code}
and have got the NPE reproduced more frequently. 
So, it looks like the test may fail if by some reason GossipTask haven't had a chance to run before EndpointState.getApplicationState is invoked as a part of the test logic.

Note: In 5.1 the test is different and does not have pullSchemaFrom logic at all.
A conversation about the issue was started in CASSANDRA-19651
Bug: Update CQL docs
Status: Open
Priority: Low
Created: 20/Aug/24 21:16

While working on the NOT operator I noticed cql_singlefile.adoc points still to CQL 3.4.3 and it was probably lacking some new updates.
I bumped the version to 3.4.7 and added the changes from the ticket I worked on but it will be good to revise and update the whole file. 
Seems like CQL.textile maybe in a similar position.
The BETWEEN operator was not added, for example.
Bug: [Analytics] Improve the core bulk reader test system to match actual and expected rows by concatenating the partition keys with the serialized hex string instead of utf-8 string
Status: Resolved
Priority: Low
Resolution: Fixed
Created: 30/Jul/24 14:51
Resolved: 03/Aug/24 06:52

The current test system for the bulk reader matches actual and expected rows by building a utf-8 string of the concatenated partition key(s), it would be better to match on the hex string of the serialized bytes to avoid the current custom string builder implementation.
Bug: [Analytics] Split the Cassandra type logic out from CassandraBridge so it can be utilized without the Spark dependency.
Status: Resolved
Priority: Low
Resolution: Fixed
Created: 22/Jul/24 23:57
Resolved: 26/Jul/24 17:26

The CassandraBridge is a monolithic class that bridges to Cassandra but for other use cases it is beneficial to access the Cassandra types independently to deserialize Cassandra data. By splitting out the Cassandra types into a separate object we can utilize Cassandra types for deserializing Cassandra raw ByteBuffers decoupled from the Spark dependency.
Bug: [Analytics] Remove other uses of Apache Commons Lang for hashcodes, equality and random string generation
Status: Resolved
Priority: Low
Resolution: Fixed
Created: 22/Jul/24 16:29
Resolved: 22/Jul/24 20:39

Apache Commons Lang is pulled in transitively by Spark but the common module does not depend on it. This change removes other uses of Apache Commons Lang for hashcode, equality checks and random string generation so more code can be moved into common module.
Bug: add keyspace name to exception message in StorageService#getEffectiveOwnership for better debugging
Status: Triage Needed
Priority: Low
Created: 02/Jul/24 14:08

 
 
{code:java}
➜ bin ./nodetool status
Datacenter: datacenter1
=======================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
-- Address Load Tokens Owns Host ID Rack
UN 127.0.0.2 235.8 KiB 16 ? f581f6fa-7192-40ab-8665-8ff270fa3fd3 rack2
UN 127.0.0.1 198.32 KiB 16 ? 00b387d8-f269-4780-878d-17648be2f218 rack1
UN 127.0.0.3 198.59 KiB 16 ? a2398380-951a-464c-a8bb-6418831715ad rack3
 
Datacenter: datacenter2
=======================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
-- Address Load Tokens Owns Host ID Rack
UN 127.0.0.11 148.47 KiB 16 ? 661da11a-08e4-4082-81e0-c33328669e8d rack1
UN 127.0.0.12 187.26 KiB 16 ? a12fe27b-fc98-4a23-9d8c-843f58562b8b rack1
 
Note: Non-system keyspaces don't have the same replication settings, effective ownership information is meaningless
{code}
I have 5 nodes and over 20 keyspaces. It's difficult for me to identify which one has different replication settings without going through each one individually, as stated in the warning note.