av9ash/GitBugs huggingface dataset:
Bug: ToolRunner added in CASSANDRA-15942 stdErr checks improvements
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 30/Jul/20 22:10
Resolved: 06/Aug/20 16:26

The JVM will output to stderr on some environments to show what flags that were picked up, when this happens all tests which validate stderr start to fail.  This was found in the org.apache.cassandra.tools.ClearSnapshotTest as it switched to use the ToolRunner; below is a sample failure on my laptop (I had to modify the asserts since they don’t include the input)

{code}
java.lang.AssertionError: 
Expecting empty but was:<"Picked up _JAVA_OPTIONS: -Djava.net.preferIPv4Stack=true
">

	at org.apache.cassandra.tools.ToolRunner.assertEmptyStdErr(ToolRunner.java:339)
	at org.apache.cassandra.tools.ToolRunner.waitAndAssertOnCleanExit(ToolRunner.java:334)
	at org.apache.cassandra.tools.ClearSnapshotTest.testClearSnapshot_RemoveMultiple(ClearSnapshotTest.java:91)
{code}


Here _JAVA_OPTIONS is used globally on my system so fails the test; there is also JAVA_TOOL_RUNNER which is used the same way.
Bug: Add dtest option to keep ccm test directories for just failed tests
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 24/Aug/20 07:22
Resolved: 24/Aug/20 14:47

DTests already have an option {{`--keep-test-dir`}} that keeps the ccm test directories. This is useful for debugging failures, especially those that can't be reproduced locally.

[Introducing|https://github.com/apache/cassandra-builds/commit/51eb85b57b62a542ca456e52a20bee06955f6ec1#diff-a885314255cf7d5c7c04889bf01aa2ab] this option to ci-cassandra.a.o [failed|https://github.com/apache/cassandra-builds/commit/d1600acde19cdbd906b0ff89318d3e8a3f400a70#diff-a885314255cf7d5c7c04889bf01aa2ab] due to lack of disk space.

This [patch|https://github.com/apache/cassandra-dtest/compare/master...thelastpickle:mck/keep_failed_test_dir] introduces a new option {{`--keep-failed-test-dir`}} that keeps the ccm test directory only for dtests that fail.

This should suffice, if disk space is still a problem, a further option of {{`--keep-failed-test-log-dir`}} can be added that only keeps the logs inside the ccm test directory, as the majority of space taken up by these directories are the cassandra data directories.
Bug: Improve log messages for socket connection/disconnection
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 24/Jul/20 22:08
Resolved: 05/Aug/20 13:43

Logging for inbound SSL connections can take place before protocol negotiation has taken place and logs a misleading cipher that could cause problems for security auditing.
  
  
{code:java}
INFO  2020-07-03T13:57:58,380 [Messaging-EventLoop-3-1] org.apache.cassandra.net.InboundConnectionInitiator:242 - connection from peer /1.1.1.1:57899 to /2.2.2.2:7000, protocol = TLSv1.2, cipher suite = SSL_NULL_WITH_NULL_NULL
{code}
 
 Instead Cassandra should log the connection & protocol, then once the cipher has been negotiated log the agreed upon cipher.
  
  
 If the inbound SSL connection does not present a client certificate, Cassandra logs this error, even if the client wasn't required to.
{code:java}
ERROR 2020-07-14T11:58:45,925 [Native-Transport-Requests-1] org.apache.cassandra.transport.ServerConnection:140 - Failed to get peer certificates for peer /4.3.2.1:59263
{code}
 
 Logging the absense of verified certificates should be a concern of the SaslNegotiator if it requires it, and not something worth alerting the operator for generally. Downgrade to debug message to make investigation possible if needed.
  
  
 Finally, to help with logging issues related to disconnection, add a log statement when an instance decides it no longer needs to keep a gossip connection open when cleaning up connections in org.apache.cassandra.net.OutboundConnections.UnusedConnectionMonitor#closeUnusedSinceLastRun
Bug: Parallelise Jenkins dtests
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 31/Jul/20 15:27
Resolved: 05/Aug/20 15:53

Currently dtests in Jenkins take ~10 hours.

Using the Jenkins Matrix plugin these jobs can be split into smaller lists of dtests and run in parallel. This is the approach CircleCI takes.

This approach was [trialed|https://github.com/apache/cassandra-builds/pull/29] with the dtest-upgrade jobs (which are not yet part of the branch pipelines, and haven't previously worked at all due to their duration).

In addition to the Matrix plugin, the Priority-Sorter and Matrix Reloaded plugins also needed to be added.

The splits will occupy all executors, and multiple builds will lead to a long build queue. More important builds (artifacts and unit tests) need a way to be prioritised in such saturated situations.

Splits can fail for silly reasons (false-positive), like [full|https://issues.apache.org/jira/browse/INFRA-19793] /tmp disks, or [connectivity issues|https://issues.apache.org/jira/browse/INFRA-20107] between the donated agent servers. The Matrix Reloaded plugin makes it easy to rebuilt just those failed splits.
Bug: Remove previously deprecated HintedHandoffManager
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 13/Jul/20 17:01
Resolved: 25/Aug/20 16:55

{{HintedHandOffManager}} was deprecated about 6 years ago:

https://github.com/apache/cassandra/commit/96d41f0e0e44d9b3114a5d80dedf12053d36a76b

with the TODO to remove it for 4.0. While looking at CASSANDRA-15582 and examining the published JMX elements it seemed sensible to remove this MBean to help clean up a bit as it appears to just be a proxy to the {{HintService}} at this point.
Bug: Fix flaky python dtest test_13595 - consistency_test.TestConsistency
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 28/Jul/20 19:17
Resolved: 12/Oct/20 18:36

https://app.circleci.com/pipelines/github/dcapwell/cassandra/355/workflows/7b8df61d-706f-4094-a206-7cdc6b4e0451/jobs/1818

{code}
>           assert 9 == jmx.read_attribute(srp, 'Count')
E           AssertionError: assert 9 == 5
{code}
Bug: testQueueWhenPoolFullStrategy - org.apache.cassandra.service.ActiveRepairServiceTest
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 07/Aug/20 00:14
Resolved: 09/Sep/20 10:58

The test is failing in CircleCI [here | https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/295/workflows/168d88ab-f55f-4560-a23e-8243aff7b1bd/jobs/1792]
Bug: Cassandra website is building/including the wrong versioned nodetool docs
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 01/Sep/20 14:32
Resolved: 24/Sep/20 12:21

For example
https://cassandra.apache.org/doc/3.11/tools/nodetool/enablefullquerylog.html

shouldn't be under the 3.11 documentation.
Bug: DOC - Fix incorrect CREATE SCHEMA command in README.asc 
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 26/Jul/20 12:09
Resolved: 29/Jul/20 12:25

It looks like no one has reviewed the contents of [{{README.asc}}|https://github.com/apache/cassandra/blob/cassandra-3.11.7/README.asc]. Instead of the {{CREATE KEYSPACE}} command, the example CQL reads:

{noformat}
cqlsh> CREATE SCHEMA schema1
       WITH replication = { 'class' : 'SimpleStrategy', 'replication_factor' : 1 };
{noformat}
Bug: Fix flaky python dtest test_view_metadata_cleanup - materialized_views_test.TestMaterializedViews
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 28/Jul/20 19:18
Resolved: 01/Oct/20 15:29

https://app.circleci.com/pipelines/github/dcapwell/cassandra/355/workflows/7b8df61d-706f-4094-a206-7cdc6b4e0451/jobs/1818

{code}
E   cassandra.OperationTimedOut: errors={'127.0.0.2': 'Client request timeout. See Session.execute[_async](timeout)'}, last_host=127.0.0.2

cassandra/cluster.py:4026: OperationTimedOut
{code}
Bug: When compaction gets interrupted, the exception should include the compactionId
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 17/Jul/20 00:18
Resolved: 08/Sep/20 23:49

When we log in compaction we use the compactionId (or taskId), because of this we can figure out the start and end log lines for compaction.  The issue is, when you interrupt a compaction task, we don’t log the compactionId, we instead log the tableId; for this reason it is much harder to attribute the interrupt to a single compactionId


Examples

{code}
INFO  2020-07-15T18:04:51,670 [CompactionExecutor:144057] org.apache.cassandra.db.compaction.CompactionTask:158 - Compacting (5a463760-c700-11ea-8982-13c71a558319) [data/ks/table/ma-27-Data.db:level=0, data/ks/table/
ma-24-Data.db:level=0, ]
INFO  2020-07-15T18:33:47,550 [CompactionExecutor:144057] org.apache.cassandra.concurrent.DebuggableThreadPoolExecutor:1942 - Compaction interrupted: Compaction@057aa994-c35b-39ec-b74d-33fba2d13bbc(ks, table, 3105436904/8658590553)bytes
{code}
Bug: Fix user experience when upgrading to 4.0 with compact tables
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 20/Aug/20 15:09
Resolved: 13/Oct/20 15:51

The code to handle compact tables has been removed from 4.0, and the intended upgrade path to 4.0 for users having compact tables on 3.x is that they must execute {{ALTER ... DROP COMPACT STORAGE}} on all of their compact tables *before* attempting the upgrade.

Obviously, some users won't read the upgrade instructions (or miss a table) and may try upgrading despite still having compact tables. If they do so, the intent is that the node will _not_ start, with a message clearly indicating the pre-upgrade step the user has missed. The user will then downgrade back the node(s) to 3.x, run the proper {{ALTER ... DROP COMPACT STORAGE}}, and then upgrade again.

But while 4.0 does currently fail startup when finding any compact tables with a decent message, I believe the check is done too late during startup.

Namely, that check is done as we read the tables schema, so within [{{Schema.instance.loadFromDisk()}}|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/service/CassandraDaemon.java#L241].  But by then, we've _at least_ called {{SystemKeyspace.persistLocalMetadata()}}} and {{SystemKeyspaceMigrator40.migrate()}}, which will get into the commit log, and even possibly flush new {{na}} format sstables. As a results, a user might not be able to seemlessly restart the node on 3.x (to drop compact storage on the appropriate tables).

Basically, we should make sure the check for compact tables done at 4.0 startup is done as a {{StartupCheck}}, before the node does anything.

We should also add a test for this (checking that if you try upgrading to 4.0 with compact storage, you can downgrade back with no intervention whatsoever).
Bug: Avoid marking shutting down nodes as up after receiving gossip shutdown message
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 01/Sep/20 20:20
Resolved: 23/Oct/20 08:48

We have two recent failures for this test on trunk: 

1.) https://app.circleci.com/pipelines/github/maedhroz/cassandra/102/workflows/37ed8dab-9da4-4730-a883-20b7a99d88b4/jobs/518/tests (CASSANDRA-15909)
2.) https://app.circleci.com/pipelines/github/jolynch/cassandra/6/workflows/41e080e0-d7ff-4256-899e-b4010c6ef5ab/jobs/716/tests (CASSANDRA-15379)

The test expects there to be mismatches and then read repair executed on a following SELECT, but either those mismatches aren’t there, read repair isn’t happening, or both.
Bug: sstablemetadata line 44: : command not found
Status: Resolved
Priority: Normal
Resolution: Cannot Reproduce
Created: 14/Aug/20 17:13
Resolved: 26/Aug/20 07:48

sstablemetadata shipped with [4.0-beta|https://issues.apache.org/jira/issues/?jql=project+%3D+CASSANDRA+AND+fixVersion+%3D+4.0-beta] is missing the code "#Use JAVA_HOME if set, otherwise look for java in PATH" and report error:

sstablemetadata: line 44: : command not found

 

The fix is to merge below code from 3.x:

^# Use JAVA_HOME if set, otherwise look for java in PATH^
^if [ -x "$JAVA_HOME/bin/java" ]; then^
 ^JAVA="$JAVA_HOME/bin/java"^
^else^
 ^JAVA="`which java`"^
^fi^

^if [ "x$JAVA" = "x" ]; then^
 ^echo "Java executable not found (hint: set JAVA_HOME)" >&2^
 ^exit 1^
^fi^
Bug: Handle difference in timestamp precision between java8 and java11 in LogFIle.java
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 14/Aug/20 15:02
Resolved: 19/Aug/20 22:28

https://bugs.openjdk.java.net/browse/JDK-8177809 made File.lastModified include milliseconds while java8 always has them as 000.

This causes problems in LogFile.java where we compare the timestamps with what we have in the logfile: [LogFile.java|https://github.com/apache/cassandra/blob/ffc8e407e087e942c4e5c40605743fe3b32d8fd5/src/java/org/apache/cassandra/db/lifecycle/LogFile.java#L234]. This means that we can throw errors when changing between java11 and 8
Bug: full query log needs improvement
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 22/Jul/20 16:34
Resolved: 27/Aug/20 21:43

When trying out full query logging as a possible integration for nosqlbench usage, I ran across many issues which would make it painful for users. Since there were several, they will be added to a single issue for now. This issue can be broken up if needed.
----
FQL doesn't work on my system, even though it says it is logging queries. 

With the following configuration in cassandra.yaml:

 
{noformat}
full_query_logging_options:
    log_dir: /REDACTED/fullquerylogs
    roll_cycle: HOURLY
    block: true
    max_queue_weight: 268435456 # 256 MiB
    max_log_size: 17179869184 # 16 GiB
    ## archive command is "/path/to/script.sh %path" where %path is replaced with the file being rolled:
    # archive_command:
    # max_archive_retries: 10
{noformat}
which appears to be the minimal configuration needed to enable fql, only a single file `directory-listing.cq4t` is created, which is a 64K sized file of zeroes.

 
----
Calling bin/nodetool enablefullquerylog throws an error initially.

[jshook@cass4 bin]$ ./nodetool enablefullquerylog

 
{noformat}
error: sun.nio.ch.FileChannelImpl.map0(int,long,long) 
-- StackTrace -- 
java.lang.NoSuchMethodException: sun.nio.ch.FileChannelImpl.map0(int,long,long) 
        at java.base/java.lang.Class.getDeclaredMethod(Class.java:2553) 
        at net.openhft.chronicle.core.OS.lambda$static$0(OS.java:51) 
        at net.openhft.chronicle.core.ClassLocal.computeValue(ClassLocal.java:53){noformat}
(full stack trace attached to this ticket)

 

Subsequent calls produce normal output:

 
{noformat}
[jshook@cass4 c4b1]$ bin/nodetool enablefullquerylog 
nodetool: Already logging to /home/jshook/c4b1/data/fullquerylogs 
See 'nodetool help' or 'nodetool help <command>'.{noformat}
 
----
nodetool missing getfullquerylog makes it difficult to verify current fullquerylog state without changing it. The conventions for nodetool commands should be followed to avoid confusing users.
----
(maybe)
{noformat}
tools/bin/fqltool help{noformat}
should print out help for all fqltool commands rather than simply repeating the default The most commonly used fqltool commands are..
----
[https://cassandra.apache.org/doc/latest/new/fqllogging.html] is malformatted, mixing the appearance of configuration with comments, which is confusing at best.
Bug: Running CQL command with non-ASCII values raises UnicodeDecodeError
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 28/Jul/20 05:03
Resolved: 19/Aug/20 15:36

There are INSERT statements that contains non-ASCII values that have run fine in Cassandra 3.11, but now raises a UnicodeDecodeError when I try executing them in 4.0-alpha4 and 4.0-beta1. 

Example input and output:
{code:java}
echo $LANG
en_US.UTF-8
$ cqlsh --debug
Using CQL driver: <module 'cassandra' from '/usr/share/cassandra/bin/../lib/cassandra-driver-internal-only-3.23.0.post0-1a184b99.zip/cassandra-driver-3.23.0.post0-1a184b99/cassandra/__init__.py'>
Using connect timeout: 5 seconds
Using 'utf-8' encoding
Using ssl: False
Connected to Cassandra Cluster at 127.0.0.1:9042.
[cqlsh 5.0.1 | Cassandra 4.0-beta1 | CQL spec 3.4.5 | Native protocol v4]
Use HELP for help.
cqlsh> CREATE KEYSPACE killr_video WITH replication = {'class': 'NetworkTopologyStrategy', 'DC-Houston': 1};
cqlsh> USE killr_video;
cqlsh:killr_video> CREATE TABLE movies_by_genre ( genre TEXT, title TEXT, year INT, duration INT, avg_rating FLOAT, country TEXT, PRIMARY KEY ((genre), title, year));
cqlsh:killr_video> INSERT INTO movies_by_genre (genre, title, year, duration, avg_rating, country)
 ... VALUES ('Action', 'The Extraordinary Adventures of Adèle Blanc-Sec', 2010, 107, 6.30, 'France');
Traceback (most recent call last):
 File "/usr/share/cassandra/bin/cqlsh.py", line 937, in onecmd
 self.handle_statement(st, statementtext)
 File "/usr/share/cassandra/bin/cqlsh.py", line 962, in handle_statement
 readline.add_history(new_hist)
UnicodeEncodeError: 'ascii' codec can't encode character u'\xe8' in position 134: ordinal not in range(128){code}
Bug: Test failures caused by merging CASSANDRA-15833
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 29/Sep/20 23:03
Resolved: 14/Oct/20 19:10

Three issues were caused by merging CASSANDRA-15833:

1. `GossiperTest#testHaveAnyVersion3Nodes` was failing on trunk: https://app.circleci.com/pipelines/github/jrwest/cassandra/53/workflows/95f9f401-1ef8-4b8d-9c64-3703d9669d95/jobs/771

2. python dtest ReadRepairTest#test_atomic_writes[blocking] was failing

3. In-jvm dtests being worked on as part of CASSANDRA-15977 uncovered an issue with how CASSANDRA-15833 changes interacted with in-jvm dtests running without {{Feature.GOSSIP}}
Bug: Add flag to disable chunk cache and disable by default
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 07/Aug/20 05:12
Resolved: 30/Sep/20 00:08

Chunk cache is enabled by default and doesn’t have a flag to disable without impacting networking.  In performance testing 4.0 against 3.0 I found that reads were slower in 4.0 and after profiling found that the ChunkCache was partially to blame; after disabling the chunk cache, read performance had improved.

{code}
40_w_cc-selects.hdr
#[Mean    =     11.50063, StdDeviation   =     13.44014]
#[Max     =    482.41254, Total count    =       316477]
#[Buckets =           25, SubBuckets     =       262144]

40_wo_cc-selects.hdr
#[Mean    =      9.82115, StdDeviation   =     10.14270]
#[Max     =    522.36493, Total count    =       317444]
#[Buckets =           25, SubBuckets     =       262144]
{code}
Bug: Upgrade of custom 3.0 version fails with custom 4.0 caused by version parsing logic
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 23/Jul/20 17:12
Resolved: 23/Jul/20 21:24

In 3.0 and earlier, custom versions could have an extra digit and could have multiple pre release tags separated by -, after upgrading to 4.0 these custom versions no longer are allowed and fail different parts of the code, any place which now uses CassandraVersion.

The issue is that version was just a String before, so the only parsing rules were controlled by the client, now CassandraVersion is used which is more restrictive.

To help out, we should allow a "hot fix" digit, and preRelease should allow multiple -
Bug: Add nodetool getfullquerylog 
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 27/Jul/20 18:04
Resolved: 02/Sep/20 16:16

This ticket is raised based on CASSANDRA-15791 and valuable feedback provided by [~jshook].

There are two outstanding questions:
 * forming the exact shape of such a command and how it can benefit the users; to be discussed in detail in this ticket
 * Is this a thing we as a project can add to 4.0 beta or it should be considered in 4.1 for example

PR: https://github.com/apache/cassandra/pull/721
Bug: Blog post on Improving Resiliency w/ "Prevent client requests from blocking on executor task queue"
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 03/Sep/20 07:42
Resolved: 03/Sep/20 07:47

Blog post on Improving Resiliency w/ "Prevent client requests from blocking on executor task queue", i.e. CASSANDRA-15013

Slack discussion: https://the-asf.slack.com/archives/CK23JSY2K/p1597025327019200

PR: https://github.com/apache/cassandra-website/pull/18
Bug: Flaky Test: TestDiskBalance.test_disk_balance_after_boundary_change_stcs
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 31/Aug/20 20:52
Resolved: 29/Sep/20 18:39

See https://app.circleci.com/pipelines/github/maedhroz/cassandra/99/workflows/72c69ea8-f347-4b00-aed8-bd465f3549ff/jobs/498

After bootstrapping a second node into the cluster, the sizes of the SSTables (per directory) on the first node no longer fall within the 10% margin of error. We don’t have any assertion in the test that they were balanced before bootstrap, however.
Bug: Jenkins pipeline can copy wrong test report artefacts from stage builds
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 07/Jul/20 09:47
Resolved: 04/Aug/20 08:57

Spotted in https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/196/console

Looks like copyArtifact will need to be specific to a build.
Bug: Fix flaky python dtest test_expiration_overflow_policy_capnowarn - ttl_test.TestTTL
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 29/Jul/20 00:35
Resolved: 16/Oct/20 19:35

https://app.circleci.com/pipelines/github/dcapwell/cassandra/361/workflows/3a42fa45-1f60-4c95-86a4-15a6773e384e/jobs/1860

{code}
>           assert warning, 'Log message should be print for CAP and CAP_NOWARN policy'
E           AssertionError: Log message should be print for CAP and CAP_NOWARN policy
E           assert []
{code}
Bug: org.apache.cassandra.cql3.validation.operations.TTLTest testCapWarnExpirationOverflowPolicy
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 17/Jul/20 23:35
Resolved: 04/Aug/20 20:28

Build: https://ci-cassandra.apache.org/job/Cassandra-trunk-test/194/testReport/junit/org.apache.cassandra.cql3.validation.operations/TTLTest/testCapWarnExpirationOverflowPolicy/
junit.framework.AssertionFailedError
	at org.apache.cassandra.cql3.validation.operations.TTLTest.checkTTLIsCapped(TTLTest.java:321)
	at org.apache.cassandra.cql3.validation.operations.TTLTest.verifyData(TTLTest.java:303)
	at org.apache.cassandra.cql3.validation.operations.TTLTest.testCapExpirationDateOverflowPolicy(TTLTest.java:248)
	at org.apache.cassandra.cql3.validation.operations.TTLTest.testCapExpirationDateOverflowPolicy(TTLTest.java:199)
	at org.apache.cassandra.cql3.validation.operations.TTLTest.testCapWarnExpirationOverflowPolicy(TTLTest.java:140)
Bug: Provide access to metrics from in-jvm dtests
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 23/Sep/20 07:21
Resolved: 14/Dec/20 13:41

Current implementation requires of in-jvm dtests requires using callOnInstance in order to get metrics out of the in-jvm test node. Since many dtests require to check metrics, we need a version-agnostic mechanism that allows us to query the value of the metric by its published name instead of peeking into internals.
Bug: SimpleQueryResult should contain client warnings
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 02/Jul/20 23:18
Resolved: 13/Jul/20 04:01

There isn't a way to get query warnings generated via \{{ClientWarn}} using the existing \{{ICoordinator}} interface. The simplest possible change here would be to...

1.) Make sure we activate warning collection before queries start.

2.) Rip warnings out of \{{ClientWarn}} when queries return.

3.) Include those warnings when we create \{{SimpleQueryResult}}.

{\{QueryResult}} might not need to expose the warnings, given not all its implementations would be expected to have them, but we could just return an empty list of warnings by default.
Bug: Occasional NEW_NODE event sent instead of NODE_UP in dTest
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 02/Jul/20 10:23
Resolved: 08/Jul/20 16:18

A new test for topology events in CASSANDRA-15677 is occasionally failing due to a NEW_NODE event sent instead of NODE_UP.

For instance: [https://app.circleci.com/pipelines/github/jasonstack/cassandra/231/workflows/cdf55335-c876-450b-8bf9-1d778a2df806/jobs/2240] 

Previously topology events were not been sent at all, so it is possible that this is a long standing bug.