av9ash/GitBugs huggingface dataset:
Bug: 4.0 quality testing: metrics
Status: In Progress
Priority: Normal
Created: 18/Feb/20 18:30

The goal of this ticket is to have a proper testing of the different metrics exposed via JMX, and to ensure that metrics that are not in used in 4.0 have been properly deprecated.

The following table show the current status of the metric tests and can be used to track the progress of that ticket:

|| Metrics || Status || test types || JIRA tickets ||
| Batch | {color:#00875A}*COVERED*{color} | unit tests | CASSANDRA-15718 | 
| BufferPool | {color:#00875A}*COVERED*{color} | unit tests | CASSANDRA-15773 |
| Cache | {color:#00875A}*COVERED*{color} | unit tests | CASSANDRA-15788 |
| Client | {color:#DE350B}*TESTS MISSING*{color}| unit tests | CASSANDRA-16216 |
| ClientRequest | {color:#00875A}*COVERED*{color} | in-jvm tests | CASSANDRA-16183 |
| ClientRequestSize | {color:#00875A}*COVERED*{color} | unit tests | CASSANDRA-16184 |
| Cache | {color:#00875A}*COVERED*{color} | unit tests | CASSANDRA-15788 |
| CommitLog | {color:#DE350B}*TESTS MISSING*{color} | unit tests | CASSANDRA-16185 |
| Compaction | {color:#DE350B}*TESTS MISSING*{color} | unit tests | CASSANDRA-16192 |
| CQL | {color:#00875A}*COVERED*{color}| unit tests | |
| HintService | {color:#DE350B}*NO TESTS*{color} | dtests | CASSANDRA-16189 |
| Messaging/Internode| {color:#DE350B}*NO TESTS*{color} | in-jvm dtests | CASSANDRA-16193 |
| ReadRepair| {color:#DE350B}*TESTS MISSING*{color} | dtests,in-jvm dtests | CASSANDRA-16187 | 
| Repair | {color:#00875A}*COVERED*{color} | in-jvm dtests | CASSANDRA-16191 |
| Storage | {color:#00875A}*COVERED*{color}| unit tests | |
| Streaming | {color:#DE350B}*NO TESTS*{color} | dtests | CASSANDRA-16190 |
| Keyspace | {color:#DE350B}*TESTS MISSING*{color} | unit tests/in-jvm dtests | CASSANDRA-16188 |
| Table | {color:#DE350B}*TESTS MISSING*{color} | unit tests/in-jvm dtests | CASSANDRA-16188 |
| ThreadPoolMetrics |{color:#00875A}*COVERED*{color} | unit tests | CASSANDRA-16186 |
Bug: Fix flakey test - org.apache.cassandra.index.sasi.SASIIndexTest testCrossSSTableQueries
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 24/Jan/20 23:39
Resolved: 19/Mar/20 20:04

{code}
junit.framework.AssertionFailedError: [key13, key2977, key2978, key2979, key2980, key2982, key2983, key2984, key2985, key6]
  at org.apache.cassandra.index.sasi.SASIIndexTest.testCrossSSTableQueries(SASIIndexTest.java:340)
  at org.apache.cassandra.index.sasi.SASIIndexTest.testCrossSSTableQueries(SASIIndexTest.java:286)
  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)
{code}
Bug: Fix flakey test - org.apache.cassandra.index.sasi.SASIIndexTest testInvalidate
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 24/Jan/20 23:40
Resolved: 19/Mar/20 19:52

{code}
junit.framework.AssertionFailedError: [key0, key2918, key2919, key2920, key2921, key2922, key2924, key2926, key2927, key2928]
	at org.apache.cassandra.index.sasi.SASIIndexTest.testInvalidate(SASIIndexTest.java:874)
	at org.apache.cassandra.index.sasi.SASIIndexTest.testInvalidate(SASIIndexTest.java:852)
	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)
{code}
Bug: StreamManager should clearly differentiate between "initiator" and "receiver" sessions
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 26/Mar/20 12:22
Resolved: 19/Jun/20 15:34

{{StreamManager}} does currently a suboptimal job in differentiating between stream sessions (in form of {{StreamResultFuture}}) which have been either initiated or "received", for the following reasons:
1) Naming is IMO confusing: a "receiver" session could actually both send and receive files, so technically an initiator is also a receiver.
2) {{StreamManager#findSession()}}  assumes we should first looking into "initiator" sessions, then into "receiver" ones: this is a dangerous assumptions, in particular for test environments where the same process could work as both an initiator and a receiver.

I would recommend the following changes:
1) Rename "receiver" with "follower" everywhere the former is used.
2) Introduce a new flag into {{StreamMessageHeader}} to signal if the message comes from an initiator or follower session, in order to correctly differentiate and look for sessions in {{StreamManager}}.

While my arguments above might seem trivial, I believe they will improve clarity and save from potential bugs/headaches at testing time, and doing such changes now that we're revamping streaming for 4.0 seems the right time.
Bug:  Add histogram to prepared statements and expose as virtual table
Status: Open
Priority: Normal
Created: 19/Feb/20 00:56

One of the biggest challenges as an operator is understanding what queries are being executed and how long they take.  We have the ability to take short samples via profileload, but it’s lacking the full diagnostics that keeping histograms on each prepared statement could give us.  Having this would be a massive benefit to most operators as they currently have no idea what Cassandra is actually doing.

Before committing let’s be sure to record some CPU flame graphs to ensure there isn’t noticeable performance overhead.
Bug: In Tree Tooling with Java 11
Status: Resolved
Priority: Normal
Resolution: Duplicate
Created: 14/Jan/20 18:28
Resolved: 09/Sep/20 04:28

This is to cover testing the various tools running on java 11.

The scope of this testing is manual testing and not automated, different JIRAs should cover automation testing these tool.

The tools in question are: nodetool, sstableloader, sstablescrub, sstableupgrade, sstableutil, sstableverify, fqltool, stress, auditlogviewer, compaction-stress, sstabledump, sstableexpiredblockers, sstablemetadata, sstableofflinerelevel, sstablesplit, and sstablerepairedset (many of these may be tested already in dtest)
Bug: 4.0 quality testing: Tooling, Bundled and First Party
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 18/Feb/20 18:31
Resolved: 23/Nov/20 11:50

Reference [doc from NGCC|https://docs.google.com/document/d/1uhUOp7wpE9ZXNDgxoCZHejHt5SO4Qw1dArZqqsJccyQ/edit#] for context.

*Shepherd: Sam Tunnicliffe*

Test plans should cover bundled first-party tooling and CLIs such as nodetool, cqlsh, and new tools supporting full query and audit logging (CASSANDRA-13983, CASSANDRA-12151).

*Progress*

{{ToolRunner}} has been added enabling us to test tools in java unit tests. This includes capturing their stdout/err and stdin i.e. Most tools have a starting unit test testing their cmd line args happy path. Tickets have been created to improve coverage of those  and flagged LHF. Also for those tools big enough they can't be addressed in a simple ticket such as nodetool, a placeholder ticket for future improvements has been created as well. Tickets and status are:
||Tool||UX test||UT coverage||dtest coverage||Comments||
|Nodetool| |(x) CASSANDRA-16026
 CASSANDRA-16230
 CASSANDRA-16200
 CASSANDRA-16227| (!)|Not all the sub commands are tested. Dtest also test nodetool as a side effect|
|Cqlsh| |(x) CASSANDRA-16025|(!)| |
|Cassandra-stress| |(x) CASSANDRA-16024|(x)| |
|debug-cql| |(x) CASSANDRA-16023|(x)| |
|fqltool|(x)|(/) CASSANDRA-16022|(!)| |
|auditlogviewer|(/) CASSANDRA-15991|(!) CASSANDRA-16021|(!)| |
|*Sstable utilities*| | | | |
|sstabledump|(/) CASSANDRA-15991|(/) CASSANDRA-16020|(!)| |
|sstableexpiredblockers|(/) CASSANDRA-15991|(x) CASSANDRA-16019|(!)| |
|sstablelevelreset|(/) CASSANDRA-15991|(x) CASSANDRA-16018|(!)| |
|sstableloader|(x)|(x) CASSANDRA-16017|(!)| |
|sstablemetadata|(/) CASSANDRA-15991|(x) CASSANDRA-16016|(x)| |
|sstableofflinerelevel|(/) CASSANDRA-15991|(x) CASSANDRA-16015|(!)| |
|sstablerepairedset|(/) CASSANDRA-15991|(x) CASSANDRA-16014|(x)|Ran in dtests, no dedicated test|
|sstablescrub|(/) CASSANDRA-15991|(x) CASSANDRA-16013|(!)| |
|sstablesplit|(/) CASSANDRA-15991|(x) CASSANDRA-16012|(!)| |
|sstableupgrade|(/) CASSANDRA-15991|(x) CASSANDRA-16011|(!)| |
|sstableutil|(/) CASSANDRA-15991|(x) CASSANDRA-16010|(!)| |
|sstableverify|(/) CASSANDRA-15991|(x) CASSANDRA-16009|(!)| |
Bug: Fix flakey testSerializeError - org.apache.cassandra.net.ConnectionTest
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 10/Mar/20 16:40
Resolved: 31/Mar/20 10:26

The test fails sometimes with the following error message and trace. 
{code:java}
processed count values don't match expected:<90> but was:<89>

junit.framework.AssertionFailedError: processed count values don't match expected:<90> but was:<89>
at org.apache.cassandra.net.ConnectionUtils$InboundCountChecker.doCheck(ConnectionUtils.java:217)
at org.apache.cassandra.net.ConnectionUtils$InboundCountChecker.check(ConnectionUtils.java:200)
at org.apache.cassandra.net.ConnectionTest.lambda$testSerializeError$24(ConnectionTest.java:494)
at org.apache.cassandra.net.ConnectionTest.lambda$doTest$8(ConnectionTest.java:240)
at org.apache.cassandra.net.ConnectionTest.doTestManual(ConnectionTest.java:260)
at org.apache.cassandra.net.ConnectionTest.doTest(ConnectionTest.java:238)
at org.apache.cassandra.net.ConnectionTest.test(ConnectionTest.java:227)
at org.apache.cassandra.net.ConnectionTest.testSerializeError(ConnectionTest.java:435){code}
Bug: Properly clean up DefaultSessionProvider#sessionCache when closing QueryReplayer
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 18/Jan/20 04:14
Resolved: 20/Jan/20 14:05

The {{DefaultSessionProvider}} used by the {{QueryReplayer}} caches the sessions by hostname. When closing, the sessions and their associated clusters are closed but they never get removed from the cache.

When connecting to the same host, the closed session is returned, which is unexpected. 

Besides the unexpected behavior, the session references remaining in the cache leaks resources.
Bug: cqlsh tests won't run on jdk1.8 (regression from CASSANDRA-10190) 
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 25/Mar/20 07:55
Resolved: 06/Apr/20 15:46

Running the cqlsh tests on jdk1.8 no longer work.

The commit {{bf9a1d487b}} for CASSANDRA-10190 broke this, by defaulting {{CASSANDRA_USE_JDK11}} to true. See https://github.com/apache/cassandra/commit/bf9a1d487b9ba469e8d740cf7d1cd419535a7e79#diff-90e40e02845884b66e9006b25250ea5cR36-R38

The following three work…
{code}
jenv shell 1.8
export CASSANDRA_USE_JDK11=false
./pylib/cassandra-cqlsh-tests.sh `pwd`
{code}
{code}
jenv shell 11.0
export CASSANDRA_USE_JDK11=true
./pylib/cassandra-cqlsh-tests.sh `pwd`
{code}
{code}
jenv shell 1.8
unset CASSANDRA_USE_JDK11
./pylib/cassandra-cqlsh-tests.sh `pwd`
{code}

The following does not…
{code}
jenv shell 1.8
./pylib/cassandra-cqlsh-tests.sh `pwd`
{code}
{noformat}
BUILD FAILED
/Users/mick/src/apache/casSANDRA/build.xml:292: -Duse.jdk11=true or $CASSANDRA_USE_JDK11=true cannot be set when building from java 8
{noformat}

JDK 1.8 is expected to be the default. With {{CASSANDRA_USE_JDK11}} being defined if/when JDK 11 is used.
Bug: Internode message builder does not add trace header
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 12/Jan/20 19:04
Resolved: 22/Jan/20 18:19

The messages built with the {{Builder}} ({{org.apache.cassandra.net.Message.Builder}}) do not have the trace header when tracing is enabled. 
Consequently, no tracing session gets propagated to other nodes, and the tracing function is broken. 

The set of static {{out*}} methods provided (to create an out-bounding message) in Message do not have the issue. They can properly add the trace header when necessary. 
To be clear, only the {{Builder}} missed adding the tracing header and it should be fixed to be consistent with the {{out*}} methods.
Bug: Race condition when completing stream sessions
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 26/Mar/20 16:31
Resolved: 24/Apr/20 09:49

{{StreamSession#prepareAsync()}} executes, as the name implies, asynchronously from the IO thread: this opens up for race conditions between the sending of the {{PrepareSynAckMessage}} and the call to {{StreamSession#maybeCompleted()}}. I.e., the following could happen:
1) Node A sends {{PrepareSynAckMessage}} from the {{prepareAsync()}} thread.
2) Node B receives it and starts streaming.
3) Node A receives the streamed file and sends {{ReceivedMessage}}.
4) At this point, if this was the only file to stream, both nodes are ready to close the session via {{maybeCompleted()}}, but:
a) Node A will call it twice from both the IO thread and the thread at #1, closing the session and its channels.
b) Node B will attempt to send a {{CompleteMessage}}, but will fail because the session has been closed in the meantime.

There are other subtle variations of the pattern above, depending on the order of concurrently sent/received messages.

I believe the best fix would be to modify the message exchange so that:
1) Only the "follower" is allowed to send the {{CompleteMessage}}.
2) Only the "initiator" is allowed to close the session and its channels after receiving the {{CompleteMessage}}.

By doing so, the message exchange logic would be easier to reason about, which is overall a win anyway.
Bug: Preview repair should include sstables from finalized incremental repair sessions
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 06/Feb/20 07:12
Resolved: 02/Mar/20 08:30

When running a preview repair we currently grab all repaired sstables, problem is that we depend on compaction to move the sstables from pending to repaired so we might have different data marked repaired on different nodes. Including any sstables from finalized incremental repair sessions as repaired will solve this.

Another problem is that validations don't start at exactly the same time on different nodes, so if an incremental repair finishes while the preview repair is running we might also validate the wrong repaired set. We should fail the preview repair if an intersecting incremental repair finishes during the preview repair.
Bug: Fix flaky test org.apache.cassandra.cql3.validation.operations.AlterTest testDropListAndAddListWithSameName
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 07/Feb/20 05:47
Resolved: 16/Mar/20 17:02

https://app.circleci.com/jobs/github/dcapwell/cassandra/482/tests

{code}
junit.framework.AssertionFailedError: Invalid value for row 0 column 2 (mycollection of type list<text>), expected <null> but got <[first element]>
	at org.apache.cassandra.cql3.CQLTester.assertRows(CQLTester.java:1070)
	at org.apache.cassandra.cql3.validation.operations.AlterTest.testDropListAndAddListWithSameName(AlterTest.java:91)
{code}
Bug:  Testsuite: org.apache.cassandra.repair.consistent.CoordinatorMessagingTest Tests run: 7, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 7.878 sec
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 27/Mar/20 17:52
Resolved: 06/Apr/20 12:36

The following failure was observed:

 Testsuite: org.apache.cassandra.repair.consistent.CoordinatorMessagingTest Tests run: 7, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 7.878 sec
[junit-timeout] 
[junit-timeout] Testcase: testMockedMessagingPrepareFailureP1(org.apache.cassandra.repair.consistent.CoordinatorMessagingTest):	FAILED
[junit-timeout] null
[junit-timeout] junit.framework.AssertionFailedError
[junit-timeout] 	at org.apache.cassandra.repair.consistent.CoordinatorMessagingTest.testMockedMessagingPrepareFailure(CoordinatorMessagingTest.java:206)
[junit-timeout] 	at org.apache.cassandra.repair.consistent.CoordinatorMessagingTest.testMockedMessagingPrepareFailureP1(CoordinatorMessagingTest.java:154)
[junit-timeout] 
[junit-timeout] 

Seen on Java8
Bug: Mismatching dependencies between cassandra dist and cassandra-all pom
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 16/Mar/20 22:44
Resolved: 14/Apr/20 18:20

I noticed that the cassandra distribution (tar.gz) dependencies doesn't match the dependency list for the cassandra-all that is available at maven central.

Cassandra distribution only includes jna 4.2.2.
But, the maven dependency also include jna-platform 4.4.0

Breakdown of relevant maven dependencies:

```
[INFO] +- org.apache.cassandra:cassandra-all:jar:4.0-alpha3:provided
[INFO] |  +- net.java.dev.jna:jna:jar:4.2.2:provided
[INFO] |  +- net.openhft:chronicle-threads:jar:1.16.0:provided
[INFO] |  |  \- net.openhft:affinity:jar:3.1.7:provided
[INFO] |  |     \- net.java.dev.jna:jna-platform:jar:4.4.0:provided
```

As you can see, jna is a direct dependency and jna-platform is a transitive dependency from chronicle-threads.


I expected this issue to had been fixed by https://github.com/apache/cassandra/pull/240/, but this change seem to have being reverted, as no longer in trunk.
Bug: Fix flaky test org.apache.cassandra.distributed.test.*RepairCoordinatorFastTest
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 21/Mar/20 01:11
Resolved: 01/Apr/20 13:14

Test failure: https://app.circleci.com/pipelines/github/dcapwell/cassandra/177/workflows/3dff37a5-9bf4-40e2-8d5b-f127b416dc79/jobs/862

{code}
[junit-timeout] Testcase: onlyCoordinator[SEQUENTIAL/true](org.apache.cassandra.distributed.test.FullRepairCoordinatorFastTest):	FAILED
[junit-timeout] nodetool command repair was successful but not expected to be. Actual: 0
[junit-timeout] junit.framework.AssertionFailedError: nodetool command repair was successful but not expected to be. Actual: 0
[junit-timeout] 	at org.apache.cassandra.distributed.api.NodeToolResult$Asserts.failure(NodeToolResult.java:76)
[junit-timeout] 	at org.apache.cassandra.distributed.test.RepairCoordinatorFast.onlyCoordinator(RepairCoordinatorFast.java:255)
[junit-timeout] 	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
[junit-timeout] 	at java.lang.Thread.run(Thread.java:748)
{code}


[Circle CI LOWER|https://circleci.com/gh/dcapwell/cassandra/tree/bug%2FrepairCoordinatorTestFlaky]
Bug: Add java.rmi.server.randomID and JAVA_HOME to system properties vtable (follow up on CASSANDRA-15616) 
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 15/Mar/20 01:42
Resolved: 17/Mar/20 20:15

Add {{java.rmi.server.randomID}} to the systems_table
System.getProperty("java.home") 
to be switched to
System.getenv("JAVA_HOME")
 
Oracle JVM might use the JRE which do not contain jmap.
Bug: flaky test org.apache.cassandra.distributed.test.SimpleReadWriteTest.readWithSchemaDisagreement
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 04/Feb/20 17:37
Resolved: 26/Mar/20 14:16

This fails infrequently, last seen failure was on java 8

{code}
junit.framework.AssertionFailedError
	at org.apache.cassandra.distributed.test.DistributedReadWritePathTest.readWithSchemaDisagreement(DistributedReadWritePathTest.java:276)
{code}
Bug: Algorithmic token allocation does not handle the racks = RF case well
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 25/Feb/20 16:01
Resolved: 03/Mar/20 16:04

When the number of racks in a data centre is equal to the replication factor, the node allocation algorithm may calculate the target ownership incorrectly and allocate unsuitable tokens. This causes some inefficiency when the number of nodes in the DC is small, and significant problems if the number of nodes in each rack is different.

In this case (racks count equal to replication factor) the load within each rack is effectively distributed independently. The allocation algorithm should reflect that, restricting the allocation space to the rack (instead of the DC) and using the RF=1 solution.
Bug: CQLSH missing virtual keyspaces on DESCRIBE call
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 18/Feb/20 03:29
Resolved: 18/Feb/20 19:33

cqlsh is missing virtual keyspaces. This patch fixes it. It also adds a dtest to avoid future regressions. [Branch|https://github.com/dineshjoshi/cassandra/tree/fix-missing-keyspace-issue-cqlsh], [DTests|https://github.com/dineshjoshi/cassandra-dtest-1/tree/fix-missing-keyspace-issue-cqlsh]  and [CI|https://circleci.com/workflow-run/b978fe37-98a8-482b-89bf-f7b6c8c41a40].
Bug: Fix flaky test org.apache.cassandra.db.ReadCommandTest purgeGCableTombstonesBeforeCalculatingDigest
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 07/Feb/20 20:36
Resolved: 11/Feb/20 09:23

https://app.circleci.com/jobs/github/dcapwell/cassandra/502/tests

{code}
junit.framework.AssertionFailedError
	at org.apache.cassandra.db.ReadCommandTest.lambda$purgeGCableTombstonesBeforeCalculatingDigest$5(ReadCommandTest.java:812)
	at java.util.Iterator.forEachRemaining(Iterator.java:116)
	at org.apache.cassandra.db.ReadCommandTest.purgeGCableTombstonesBeforeCalculatingDigest(ReadCommandTest.java:805)
{code}
Bug: StorageProxy updateCoordinatorWriteLatencyTableMetric can produce misleading metrics
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 12/Feb/20 19:54
Resolved: 14/Feb/20 21:49

If multiple mutations affect the same table, then metrics will get posted multiple times to the same table.

[Circle CI|https://circleci.com/gh/dcapwell/cassandra/tree/coordinatorWriterMetricDoubleCounts]
Bug: Incorrect Outcome returned when acquiring capacity for incoming message
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 28/Feb/20 11:27
Resolved: 07/Apr/20 13:54

When acquiring capacity to process an inbound internode message, a failure to allocate from the endpoint-specific reserve returns the wrong {{Outcome}}. This means we only ever register with {{globalWaitQueue}}, although this probably doesn't actually ever get detected as the global and endpoint queues are always signalled together.
Bug: Fix flaky test org.apache.cassandra.db.repair.PendingAntiCompactionBytemanTest.testExceptionAnticompaction
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 05/Feb/20 19:02
Resolved: 03/Mar/20 07:59

{code}
junit.framework.AssertionFailedError
	at org.apache.cassandra.db.repair.PendingAntiCompactionBytemanTest.testExceptionAnticompaction(PendingAntiCompactionBytemanTest.java:80)
	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)
	at org.jboss.byteman.contrib.bmunit.BMUnitRunner$9.evaluate(BMUnitRunner.java:364)
	at org.jboss.byteman.contrib.bmunit.BMUnitRunner$6.evaluate(BMUnitRunner.java:263)
	at org.jboss.byteman.contrib.bmunit.BMUnitRunner$1.evaluate(BMUnitRunner.java:97)
{code}

Failure was on java 11
Bug: StreamResultFuture check for completeness is inconsistent, leading to races
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 27/Mar/20 11:23
Resolved: 25/May/20 14:54

{{StreamResultFuture#maybeComplete()}} uses {{StreamCoordinator#hasActiveSessions()}} to determine if all sessions are completed, but then accesses each session state via {{StreamCoordinator#getAllSessionInfo()}}: this is inconsistent, as the former relies on the actual {{StreamSession}} state, while the latter on the {{SessionInfo}} state, and the two are concurrently updated with no coordination whatsoever.

This leads to races, i.e. apparent in some dtest spurious failures, such as {{TestBootstrap.resumable_bootstrap_test}} in CASSANDRA-15614 cc [~e.dimitrova].