av9ash/GitBugs huggingface dataset:
Bug: Test Failure: org.apache.cassandra.audit.AuditLoggerAuthTest
Status: Open
Priority: Normal
Created: 26/Feb/24 21:08

The tests in this class are flaky for current trunk, as seen in this run:

[https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra?branch=AuditLoggerAuthTest-trunk]

org.apache.cassandra.audit.AuditLoggerAuthTest.testUNAUTHORIZED_ATTEMPTAuditing-_jdk17
{code:java}
junit.framework.AssertionFailedError: expected:<LOGIN_SUCCESS> but was:<LOGIN_ERROR> at org.apache.cassandra.audit.AuditLoggerAuthTest.executeWithCredentials(AuditLoggerAuthTest.java:374) at org.apache.cassandra.audit.AuditLoggerAuthTest.testUNAUTHORIZED_ATTEMPTAuditing(AuditLoggerAuthTest.java:252) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43){code}
testCqlLoginAuditing-_jdk17
{code:java}
junit.framework.AssertionFailedError: expected:<LOGIN_SUCCESS> but was:<LOGIN_ERROR> at org.apache.cassandra.audit.AuditLoggerAuthTest.executeWithCredentials(AuditLoggerAuthTest.java:374) at org.apache.cassandra.audit.AuditLoggerAuthTest.testCqlLoginAuditing(AuditLoggerAuthTest.java:119) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43){code}
testCqlLISTROLESAuditing-_jdk17
{code:java}
junit.framework.AssertionFailedError: expected:<LOGIN_SUCCESS> but was:<LOGIN_ERROR> at org.apache.cassandra.audit.AuditLoggerAuthTest.executeWithCredentials(AuditLoggerAuthTest.java:374) at org.apache.cassandra.audit.AuditLoggerAuthTest.testCqlLISTROLESAuditing(AuditLoggerAuthTest.java:209) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43){code}
testCqlCreateRoleAuditing-_jdk17
{code:java}
junit.framework.AssertionFailedError: expected:<LOGIN_SUCCESS> but was:<LOGIN_ERROR> at org.apache.cassandra.audit.AuditLoggerAuthTest.executeWithCredentials(AuditLoggerAuthTest.java:374) at org.apache.cassandra.audit.AuditLoggerAuthTest.createTestRole(AuditLoggerAuthTest.java:424) at org.apache.cassandra.audit.AuditLoggerAuthTest.testCqlCreateRoleAuditing(AuditLoggerAuthTest.java:127) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43){code}
Bug: Test Failure: testGettingSchemaVersion
Status: Open
Priority: Normal
Created: 12/Mar/24 09:07

[Failure|https://app.circleci.com/pipelines/github/bereng/cassandra/1185/workflows/280a09fd-75f7-447e-b94d-9224df3e5045/jobs/39584/tests] of org.apache.cassandra.schema.SchemaTest.testGettingSchemaVersion

{noformat}
junit.framework.AssertionFailedError: 
Expecting value to be true but was false expected:<[tru]e> but was:<[fals]e>
	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.schema.SchemaTest.testGettingSchemaVersion(SchemaTest.java:193)
	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)
{noformat}
Bug: pytest >= 8.1.0 breaks flaky plugin in cassandra-dtests
Status: Open
Priority: Normal
Created: 09/Mar/24 20:16

I just hit this issue literally today / yesterday. Python's dtests started to fail on some super strange errors like this (1) and similar ... 

We have "pytest>=6.5.0" in requirements.txt for Python dtests so it seems like it automatically updates to whatever is the latest and it just updated to 8.1.1 and it broke the stuff.

Some basic investigation yields (2), (3) were complaints are made that it break a lot of things.

The proper solution seems to be to remove flaky and transition to (4).

Until we fix this, I think we might just downgrade to the latest 8.0.x pytest, probably this one (5), I am just trying it as I write this.

(1) https://app.circleci.com/pipelines/github/instaclustr/cassandra/3978/workflows/57f7db32-9892-40bd-9e85-cc9527af7af7/jobs/201511
(2) https://github.com/pytest-dev/pytest/issues/12066
(3) https://docs.pytest.org/en/latest/changelog.html#pytest-8-1-0-yanked
(4) https://github.com/pytest-dev/pytest-rerunfailures
(5) https://docs.pytest.org/en/latest/changelog.html#pytest-8-0-2-2024-02-24
Bug: Test Failure: org.apache.cassandra.distributed.test.UpgradeSSTablesTest.truncateWhileUpgrading
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 14/Feb/24 16:14
Resolved: 06/Mar/24 08:35

[https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/2646/workflows/bc2bba74-9e56-4bea-8de7-4ff840c4f450/jobs/56028/tests#failed-test-0]


{code:java}
junit.framework.AssertionFailedError at org.apache.cassandra.distributed.test.UpgradeSSTablesTest.truncateWhileUpgrading(UpgradeSSTablesTest.java:220) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43){code}
Bug: test_complementary_deletion_with_limit_on_partition_key_column_with_empty_partitions fails with SAI
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 06/Mar/24 10:05
Resolved: 06/Mar/24 12:44

The dtest {{replica_side_filtering_test::TestSecondaryIndexes::test_complementary_deletion_with_limit_on_partition_key_column_with_empty_partitions}} fails when the default secondary index is switched to SAI with
{code}
test_complementary_deletion_with_limit_on_partition_key_column_with_empty_partitions failed; it passed 0 out of the required 1 times.
	<class 'ccmlib.node.ToolError'>
	Subprocess ['nodetool', '-h', 'localhost', '-p', '7200', 'flush'] exited with non-zero status; exit status: 2; 
stderr: error: null
-- StackTrace --
java.lang.NullPointerException
	at java.base/java.util.Objects.requireNonNull(Objects.java:209)
	at org.apache.cassandra.index.sai.disk.v1.segment.SegmentMetadata.<init>(SegmentMetadata.java:102)
	at org.apache.cassandra.index.sai.disk.v1.MemtableIndexWriter.flush(MemtableIndexWriter.java:166)
	at org.apache.cassandra.index.sai.disk.v1.MemtableIndexWriter.complete(MemtableIndexWriter.java:125)
	at org.apache.cassandra.index.sai.disk.StorageAttachedIndexWriter.complete(StorageAttachedIndexWriter.java:185)
	at java.base/java.util.ArrayList.forEach(ArrayList.java:1511)
	at java.base/java.util.Collections$UnmodifiableCollection.forEach(Collections.java:1092)
	at org.apache.cassandra.io.sstable.format.SSTableWriter.commit(SSTableWriter.java:289)
	at org.apache.cassandra.io.sstable.SimpleSSTableMultiWriter.commit(SimpleSSTableMultiWriter.java:90)
	at org.apache.cassandra.db.ColumnFamilyStore$Flush.flushMemtable(ColumnFamilyStore.java:1354)
	at org.apache.cassandra.db.ColumnFamilyStore$Flush.run(ColumnFamilyStore.java:1253)
	at org.apache.cassandra.concurrent.ExecutionFailure$1.run(ExecutionFailure.java:133)
	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}

Discovered while testing CASSANDRA-18753.
Bug: Optimize pre-commit test suite
Status: Triage Needed
Priority: Normal
Created: 16/Feb/24 09:38

See the following ML threads:
 * Branimir discussing having 2 supported configs which included a lot of back and forth about what we're testing: [link|https://lists.apache.org/thread/qf5c3hhz6qkpyqvbd3sppzlmftlc0bw0]
 * Follow up DISCUSS thread notifying about this ticket: [link|https://lists.apache.org/thread/r433j1mk111v102z4nr1m9l1fqf41fbr]

The pre-commit test suite has a lot of redundancy in our current approach while also leaving certain configurations untested or undertested. We need to address both sides of this.
Bug: [Analytics] Use constant reference time during bulk read process
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 29/Feb/24 18:24
Resolved: 05/Mar/24 19:07

Bulk reader leverages a time provider that returns the current time during read to guide compaction and validation.

As the current time value varies in spark executors, there is a chance that rows/cells get expired inconsistently. Another issue is the validation on no-expired rows/cells after compaction might fail, since they could expire during read. The read can take minutes or even hours.
It could lead to false data omission and job failure.

The fix is to use constant reference time that is decided by Spark driver and distribute to all executors. The reference time is used for compaction and validation later.
Bug: Create Trigger is not working on 4.x version cassandra
Status: Resolved
Priority: Normal
Resolution: Not A Problem
Created: 02/Mar/24 20:42
Resolved: 04/Mar/24 12:22

Current version is 3.11.16  , try to upgrade 4.0.0 , 4.0.5 ,4.0.12 and both of 4.x version gives below error.

 

Reload triggers is executed , custom trigger jar put in correct path "../conf/triggers".

 

cassandra@cqlsh:radius> CREATE TRIGGER radacct_trigger ON radius.radacct USING 'com.XXXX.cassandra.trigger.RadAcctTrigger';

 

InvalidRequest: Error from server: code=2200 [Invalid query] message="Trigger class 'com.XXXX.cassandra.trigger.RadAcctTrigger' couldn't be loaded"
Bug: Investigate a different way how to verify CQLSSTableWriterTest data after loading
Status: Triage Needed
Priority: Normal
Created: 22/Jan/24 12:24

In CASSANDRA-18714, we realized that client tests (CQLSSTableWriterClientTest) are not executing the same set of tests as CQLSSTableWriterTest does. This unfortunate discrepancy was addressed in CASSANDRA-18714 were both client and daemon tests extend abstract test class where all tests are hence client and daemon run same tests, just from different angle.

This clear improvement in the consolidation of tests is not 100% pure in trunk. Due to nature of the implementation in trunk, the only thing which is skipped in trunk is verification of data after generated SSTables are loaded in case of client tests. This was not done before CASSANDRA-18714 either (because client tests were not testing what daemon ones would in the first place). 

This ticket is for the investigation how to unify tests for both modes in trunk, we might probably load SSTables on the disk by means of SSTableScanner, for example.
Bug: Support building with JDK17
Status: Resolved
Priority: Normal
Resolution: Invalid
Created: 28/Feb/24 18:57
Resolved: 28/Feb/24 19:24

We're saying that C* has experimental JDK 17 support yet the 5.0 branch can't be built with it.  

 
{noformat}
ubuntu@ip-172-31-36-36:/usr/local/cassandra/current$ ant
Buildfile: /usr/local/cassandra/trunk/build.xml
     [echo] Non default JDK version used: 17
init:
BUILD FAILED
/usr/local/cassandra/trunk/build.xml:388: Directory /usr/local/cassandra/trunk/build/classes/main creation was not successful for an unknown reason
Total time: 1 second
ubuntu@ip-172-31-36-36:/usr/local/cassandra/current$ java -version
openjdk version "17.0.10" 2024-01-16
OpenJDK Runtime Environment (build 17.0.10+7-Ubuntu-122.04.1)
OpenJDK 64-Bit Server VM (build 17.0.10+7-Ubuntu-122.04.1, mixed mode, sharing)
{noformat}
Trying to use a similar flag to -Duse.jdk11=true fails as well:

 
{noformat}
ubuntu@ip-172-31-36-36:/usr/local/cassandra/current$ ant -Duse.jdk17=true
Buildfile: /usr/local/cassandra/trunk/build.xml
     [echo] Non default JDK version used: 17init:BUILD FAILED
/usr/local/cassandra/trunk/build.xml:388: Directory /usr/local/cassandra/trunk/build/classes/main creation was not successful for an unknown reasonTotal time: 0 seconds{noformat}
I see this in build.xml:
{noformat}
<property name="java.supported" value="11,17" />{noformat}
 

I think a bigger picture question is, why do we require special flags to build different JVM versions?  Is this a limitation of ant, or the way we've configured it?
Bug: Tests failing for ppc64le architecture.
Status: Triage Needed
Priority: Normal
Created: 23/Feb/24 08:13

{color:#000000}Hi Team,{color}

{color:#000000}I am working on validating Cassandra on ppc64le architecture, I have followed the following steps to build Cassandra-4.1.4 from source:{color}

{color:#000000} {color}

{color:#000000}1. Install java-11, python3.7, ant, cmake,ninja.{color}

{color:#000000}2. Build netty-tcnative and transport-native-epoll from source since jars are not available for ppc64le.{color}

{color:#000000}3. Clone Cassandra repository, checked out to cassandra-4.1.4.
{color}

{color:#000000}4. Command used to build: ant{color}

{color:#000000}5. Command used to test: ant test

{color}

{color:#000000}6 tests mentioned below are failing:{color}

{color:#000000}FullQueryLoggerTest {color}

{color:#000000}SSTableReaderTest {color}

{color:#000000}FileTest {color}

{color:#000000}SystemPropertiesBasedFileSystemOwnershipCheckTest{color}

{color:#000000}YamlBasedFileSystemOwnershipCheckTest 
DescriptorTest

{color}{color:#000000}I have observed same tests failing on x86 architecture. Please find attached the logs for the failing tests below.{color}

{color:#000000}
Additional details:{color}

{color:#000000}OS: Red Hat Enterprise Linux 8.7{color}

{color:#000000} {color}

{color:#000000}Any suggestions and pointers regarding the same will be helpful.{color}

{color:#000000} {color}

{color:#000000} {color}
Bug: Add way for SAI to disable row to token index so internal tables may leverage SAI
Status: Resolved
Priority: Normal
Resolution: Won't Fix
Created: 05/Feb/24 19:08
Resolved: 27/Feb/24 18:34

Internal tables tend to use LocalPartitioner and may not actually have murmur tokens but rather LocalPartitioner, which is variable length bytes tokens!  For internal use cases we don’t always care about paging so don’t really need this index to function.

The use case motivating this work is for Accord, we wish to add a custom SAI index on the system_accord.commands#routes column.  Since this logic is purely internal we don’t care about paging, but can not leverage SAI at this moment as it hard codes murmur tokens, and fails during memtable flush
Bug: expired data in sstable not remove
Status: Resolved
Priority: Normal
Resolution: Not A Problem
Created: 22/Feb/24 07:14
Resolved: 22/Feb/24 08:32

Version: cassandra:3.11.3

 

My table is using a TTL of 90 days. but sometimes expired data not deleted, The file size will increase to several hundred gigabytes, occupying a large amount of disk space.

Liked this sstable file:

-rw-r--r-- 1 cassandra cassandra 396G Sep 10 00:16 mc-22009-big-Data.db
-rw-r--r-- 1 cassandra cassandra    9 Sep 10 00:16 mc-22009-big-Digest.crc32
-rw-r--r-- 1 cassandra cassandra  37K Sep 10 00:16 mc-22009-big-Filter.db
-rw-r--r-- 1 cassandra cassandra 533M Sep 10 00:16 mc-22009-big-Index.db
-rw-r--r-- 1 cassandra cassandra  12K Sep 10 00:16 mc-22009-big-Statistics.db
-rw-r--r-- 1 cassandra cassandra  15K Sep 10 00:16 mc-22009-big-Summary.db
-rw-r--r-- 1 cassandra cassandra   92 Sep 10 00:16 mc-22009-big-TOC.txt

By using sstabledump tool, i found all rows expired

    17        {
    18          "type" : "row",
    19          "position" : 104,
    20          "clustering" : [ 1689491660981 ],
    21          "liveness_info" : \{ "tstamp" : "2023-07-16T07:14:24.273004Z", "ttl" : 7776000, "expires_at" : "2023-10-14T07:14:24Z", "expired" : true },
    22          "cells" : [
    23            \{ "name" : "long_v", "value" : 1 }
    24          ]
    25        }

 

This issue makes my disk space estimation unpredictable, so i want get some help.

The attachment contains information on sstablemetadata.
Bug: WEBSITE - Catalysts and community page udpates
Status: Triage Needed
Priority: Normal
Created: 22/Feb/24 21:31

* Updating the PMC list on the community page.
 * Adding Catalyst bios and images to the Apache Cassandra Catalysts page

Previews available:

https://raw.githack.com/Paul-TT/cassandra-website/CASSANDRA-19423_generated/content/_/cassandra-catalyst-program.html

https://raw.githack.com/Paul-TT/cassandra-website/CASSANDRA-19423_generated/content/_/community.html
Bug: [Analytics] Bulk reader fails to produce a row when regular column values are null
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 19/Feb/24 18:53
Resolved: 22/Feb/24 00:18

Bulk Reader won't emit a row when the regular column values are all null. For example,
a schema {{PK}} = {{a,b}} ; {{CK}} = {{c,d}} ; and columns = {{e,f}}

|| a    || b     || c    || d     || e     || f      ||
| {{pk1}} |  {{pk2}} | {{ck1}} |  {{ck2}} |  {{null}} |  {{null}} |

when queried from bulk reader, it won't produce a row.
Bug: Batch size guardrail ignores primary key size
Status: Triage Needed
Priority: Normal
Created: 20/Feb/24 09:39

{color:#1f2328}The size of a mutation does not consider the primary key size. In the context of BATCHed mutations, this means that INSERTs, DELETEs, and UPDATEs for tables with a simple PRIMARY KEY and no clustering columns would be equal to zero (or almost zero depending on the version). Consequently, the batch_size_fail_threshold_in_kb has no effect for such tables, and it cannot protect the cluster from being overloaded.{color}

{color:#1f2328}A test that reproduces the problem in 3.11 - [https://github.com/szymon-miezal/cassandra/commit/50b27c1e9030ce5ace6a6486a9876493c4ad41ae#diff-8cb249caec219439da461a4369f20530bb7d6cc0467c7e46f16288e22b574e61R43] {color}

{color:#1f2328}There are a few ways it could be solved:{color}
 * {color:#1f2328}Modifying the existing batch_size_fail_threshold_in_kb to take into account the primary keys size (it has the disadvantage of changing the semantic of the guardrail thus introducing a regression).{color}
 * {color:#1f2328}Adding a new guardrail e.g. batch_size_with_pk_fail_threshold_in_kb that is going to be calculated taking primary key into account.{color}
 * Adding a -D switch that by default would be {{false}}{color:#1f2328} meaning that in case the new formula (which takes PK into account) yields value over the error threshold it will gracefully tell us about it in an additional log message. Changing the flag value to {color}{{true}}{color:#1f2328} would be equivalent to the new formula and error will be thrown in case we get over the threshold.{color}

{{{color:#1f2328}I have a preference for going with an option that adds a new guardrail.{color}}}
Bug: (Accord) AsyncChain.flatMap does not begin the result of the flatMap, which causes AsyncLoader to hang in some cases
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 15/Feb/24 17:59
Resolved: 19/Feb/24 22:36

While a Node is in the Saving state, but linked, we can call org.apache.cassandra.service.accord.AccordStateCache#maybeEvictSomeNodes which will promote the value to Loaded.  Now that the node is Loaded we are allowed to evict it!
Bug: Rethink dumping of cluster metadata via CMSOperationsMBean
Status: Resolved
Priority: Normal
Resolution: Won't Fix
Created: 14/Feb/24 14:29
Resolved: 16/Feb/24 12:46

I think there are two problems in the implementation of dumping ClusterMetadata in CMSOperationsMBean

1) A dump is saved in a file and dumpClusterMetadata methods will return just a file name where that dump is. However, nodetool / JMX call to MBean (or any place this method is invoked from, we would like to offer a command in nodetool which returns the dump) is meant to be used from anywhere, remotely, so what happens when we execute nodetool or call these methods on a machine different from a machine a node runs on? E.g. admins can just have some jumpbox to a cluster they manage, they do not necessarily have access to nodes themselves. So they would not be able to read it.

2) It creates temp file which is not deleted so /tmp will be populated with these dumps until node is turned off which might take a lot of time and can consume a lot of disk space if dumps are done frequently and they are big. An adversary might just dump cluster metadata until no disk space is left.

What I propose is that we would return all dump string, not just a filename where we save it. We can also format the output on the client or we can tell server what format we want the dump to be returned in. 

If there is a concern about size of data to be returned, we might optionally allow dumps to be returned as compressed by simple zipping on server and unzipping on client where "zipper" is a standard java.util.zip so it basically doesn't matter what jvm runs on client and server.
Bug: Improve SAI index type handling
Status: Triage Needed
Priority: Normal
Created: 15/Feb/24 13:00

There are now 3 different index types supported by SAI :- literal, numeric & vector. These each have different in-memory, on-disk & search requirements.

Currently, the different types are supported using conditional statements throughout the SAI codebase.

It would be better if each index type was represented by a strategy that provided the non-specific SAI code with the support needed to handle the index type.

This would make it far easier to add additional index types in the future.
Bug: Flaky Host replacement tests and shrink tests (Instance class loader is already closed)
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 22/Jan/24 20:06
Resolved: 13/Feb/24 22:13

During Circle CI runs there are some flaky integration tests, some noticed are
 * HostReplacementMultiDCTest
 * HostReplacementMultiDCFailureTest
 * HostReplacementFailureTest
 * LeavingSingleFailureTest

Some of the error message I see in these tests are e.g.

{code:java}
java.lang.RuntimeException: java.lang.IllegalStateException: Can't load org.apache.cassandra.utils.concurrent.Ref$OnLeak. Instance class loader is already closed.
{code}


On repeated run, these tests pass.
Bug: Warn when native_transport_port_ssl is set
Status: Open
Priority: Normal
Created: 14/Feb/24 14:51

In CASSANDRA-19392 this was deprecated, however Stefan notes that if you set this it will work in a single node cluster because the peers table isn't needed to distribute the information.  This sounds like a recipe for "this worked when we tested in development, but not in production" so it would be good to warn users when this is set to avoid future confusion.