av9ash/GitBugs huggingface dataset:
Bug: Test Failure: dtest-upgrade.upgrade_tests.cql_tests.TestCQLNodes3RF3_Upgrade_current_3_0_x_To_indev_4_1_x.test_multi_in_compact (from Cassandra dtests)
Status: Resolved
Priority: Normal
Resolution: Duplicate
Created: 13/May/22 18:30
Resolved: 02/Jun/22 15:22

Flakes on this and another permutation RF combination
{code}
Error Message test teardown failure
Stacktrace

Unexpected error found in node logs (see stdout for full details). Errors: [[node1] 'ERROR [Messaging-EventLoop-3-7] 2022-05-10 09:24:59,879 NoSpamLogger.java:111 - /127.0.0.1:7000->/127.0.0.3:7000-URGENT_MESSAGES-[no-channel] failed to connect\nio.netty.channel.unix.Errors$NativeIoException: readAddress(..) failed: Connection reset by peer']
{code}
[https://ci-cassandra.apache.org/job/Cassandra-4.1/10/testReport/dtest-upgrade.upgrade_tests.cql_tests/TestCQLNodes3RF3_Upgrade_current_3_0_x_To_indev_4_1_x/test_multi_in_compact/]


Nightlies archive if above is dropped: [https://nightlies.apache.org/cassandra/ci-cassandra.apache.org/job/Cassandra-4.1/10/testReport/dtest-upgrade.upgrade_tests.cql_tests/TestCQLNodes3RF3_Upgrade_current_3_0_x_To_indev_4_1_x/test_multi_in_compact/]
Bug: Missing type checking on reused bind variables
Status: Open
Priority: Normal
Created: 15/Jun/22 16:59

A bind variable gets its type from its context (e.g. in {{INSERT INTO tab(a) VALUES(:var)}}, {{:var}} has the same type as {{tab.a}}. But what if the same variable is used in contexts that have different types? Assume {{a}} and {{b}} have incompatible types:

{{INSERT INTO ks.tab (id, a, b) VALUES(:id, :a, :a)}}


The server should reject the query, but it doesn't.

I think what happens is that one :a shadows the other, so the other :a can't even get a value.

More complete reproducer attached.
Bug: nodetool compact should support using a key string to find the range to avoid operators having to manually do this
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 07/Apr/22 20:57
Resolved: 22/Apr/22 22:37

Its common that a single key needs to be compact, and operators need to do the following

1) go from key -> token
2) generate range
3) call nodetool compact with this range

We can simply this workflow by adding this to compact

nodetool compact ks.tbl -k “key1"
Bug: Add missing information about whether to drop sstables or not when dropping schema objects
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 26/Apr/22 12:42
Resolved: 28/Feb/23 16:07

This is the missed piece in SchemaChangeListener - when the implementation of SchemaUpdateHandler decides to say drop a table but keep sstables, that information about not-dropping sstables is not propagated to the SchemaChangeListener
Bug: Fix testMetricsWithRebuildAndStreamingToTwoNodes
Status: Open
Priority: Normal
Created: 05/May/22 23:21

[https://ci-cassandra.apache.org/job/Cassandra-4.1/4/testReport/org.apache.cassandra.distributed.test.metrics/StreamingMetricsTest/testMetricsWithRebuildAndStreamingToTwoNodes/]

 
h3.  
{code:java}
Error Message
[The amount of files received by node2 from node3 is not the expected one. [expected: 5, actual: 6]] expected:<[5]L> but was:<[6]L>

Stacktrace
junit.framework.AssertionFailedError: [The amount of files received by node2 from node3 is not the expected one. [expected: 5, actual: 6]] expected:<[5]L> but was:<[6]L> at org.apache.cassandra.distributed.test.metrics.StreamingMetricsTest.lambda$checkDataReceived$e7abd6ea$1(StreamingMetricsTest.java:368) at org.apache.cassandra.concurrent.FutureTask$1.call(FutureTask.java:81) at org.apache.cassandra.concurrent.FutureTask.call(FutureTask.java:47) at org.apache.cassandra.concurrent.FutureTask.run(FutureTask.java:57) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) at io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30) at java.lang.Thread.run(Thread.java:748)
{code}
Bug: Address CASSANDRA-16844 and CASSANDRA-16976 breaking compatibility
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 07/Jun/22 00:22
Resolved: 29/Jun/22 15:20

Compactionstats changed the output format, which causes a breaking change in a minor release; this goes against the projects guidelines for a minor release and needs to be addressed before releasing 4.1
Bug: Documentation from Partition Denylist Lost in Document Migration + Minor Fixes
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 12/Apr/22 17:58
Resolved: 17/Jan/23 08:29

The documentation added in https://issues.apache.org/jira/browse/CASSANDRA-12106 went missing when the documents were migrated to the new format. We just need to bring the doc back. Along with this fix there are a couple minor edits to make to the document itself to correct the examples.
Bug: SSTable Version documentation out of sync with code
Status: Open
Priority: Normal
Created: 13/Apr/22 13:00

The website documentation around [SSTable Versions|https://cassandra.apache.org/doc/latest/cassandra/architecture/storage_engine.html#sstable-versions] is out of sync with the [source code comments|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/io/sstable/format/big/BigFormat.java#L118], on both the 3.11 and the current trunk branches.

As the source code appears to be kept current with the code, it would be beneficial to keep the documentation automatically up-to-date with the source code.
Bug: Remove commons-lang dependency during build runtime
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 30/Jun/22 17:11
Resolved: 07/Jul/22 00:47

{{commons-lang}} is not a runtime dependency and a {{java.lang.NoClassDefFoundError: org/apache/commons/lang/StringUtils}} exception is encountered during startup when hitting the codepath in {{{}StartupClusterConnectivityChecker{}}}.

This error is encountered very infrequently, but it has the potential of preventing the {{CassandraDaemon}} from starting up.

Currently, the Cassandra project allows developers to import the {{org.apache.commons.lang.\*}} namespace. The Cassandra build process should fail when {{org.apache.commons.lang.\*}} namespace imports are added to the code. This will prevent anyone from adding a build runtime library that is not available during runtime.
Bug: Fix testRemoteStreamFailure
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 21/Jun/22 21:04
Resolved: 05/Jul/22 23:58

Failing on trunk: 
{code:java}
Error Message
java.util.concurrent.TimeoutException

Stacktrace
java.lang.RuntimeException: java.util.concurrent.TimeoutException at org.apache.cassandra.utils.Throwables.maybeFail(Throwables.java:73) at org.apache.cassandra.utils.FBUtilities.waitOnFutures(FBUtilities.java:509) at org.apache.cassandra.distributed.impl.AbstractCluster.close(AbstractCluster.java:1028) at org.apache.cassandra.distributed.test.RepairErrorsTest.testRemoteStreamFailure(RepairErrorsTest.java:179) 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) Caused by: java.util.concurrent.TimeoutException at org.apache.cassandra.utils.concurrent.AbstractFuture.get(AbstractFuture.java:253) at org.apache.cassandra.utils.FBUtilities.waitOnFutures(FBUtilities.java:501)
{code}
Bug: Fix AbstractCell#toString throws MarshalException for cell in collection
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 16/Jun/22 21:50
Resolved: 30/Jun/22 01:17

AbstractCell#toString is broken when calling on some cells in multi-cell collections.

With the following types are unmarshallable: [date, duration, smallint, time, tinyint].

The test to discover the unmarshallable types is
{code:java}
@Test
public void testUnmarshallableInMulticellCollection()
{
    List<CQL3Type.Native> unmarshallableTypes = new ArrayList<>();
    for (CQL3Type.Native nativeType : CQL3Type.Native.values())
    {
        ColumnMetadata c = fakeColumn("c", MapType.getInstance(Int32Type.instance, nativeType.getType(), true));
        BufferCell cell = BufferCell.tombstone(c, 0, 4, CellPath.create(ByteBufferUtil.bytes(4)));
        try
        {
            cell.toString();
        }
        catch (MarshalException m)
        {
            unmarshallableTypes.add(nativeType);
        }
    }
    System.out.println("Unmarshallable types: " + unmarshallableTypes);
}
{code}
At the first sight, the error is caused by trying to deserialize the values of the tombstone cells. The values are empty, hence the failure.
Bug: Fix test_parallel_upgrade_with_internode_ssl
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 20/Apr/22 15:09
Resolved: 24/May/22 11:19

While working on CASSANDRA-17341 I hit this flaky test, very rarely failing but it is failing on trunk.

More info in this CI run:

https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/1563/workflows/61bda0b7-f699-4897-877f-c7d523a03127/jobs/10318
Bug: WEBSITE - May 2022 blog "The Path to Green CI"
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 19/May/22 01:25
Resolved: 19/May/22 14:16

This ticket is to capture the work associated with publishing the May 2022 blog "The Path to Green CI"

If this blog cannot be published by the *May 19, 2022 publish date*, please contact me, suggest changes, or correct the date when possible in the pull request for the appropriate time that the blog will go live (on both the blog.adoc and the blog post's file).
Bug: Clients using JMX are unable to handle non-standard java types but we leak this into our interfaces
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 05/Apr/22 21:33
Resolved: 08/Apr/22 20:23

JMX clients only work if-and-only-if they have the same types defined by the interface, so non-standard java (or javax) types should never be used; we currently rely on humans to block this in review, which has lead to a few interfaces exposing Cassandra types
Bug: Move TombstoneOverwhelmingException into org.apache.cassandra.exceptions package
Status: Triage Needed
Priority: Normal
Created: 02/May/22 05:03

*Issue Description*

 

Package _*org.apache.cassandra.db.filter*_ is a promiscuous package, and groups together miscellaneous functionalities that might be useful to different subsystems. I found that class _*TombstoneOverwhelmingException*_ is not used by classes in its package{_}.{_} During the development process, one groups together classes (that often co-change) with similar responsibilities in one package to facilitate maintenance, which prevents a change that causes other packages to be modified.

Location: The source file can be found at path File src/java/org/apache/cassandra/db/filter/TombstoneOverwhelmingException.java

 

*Refactoring suggestions*

 

I suggest that class _*TombstoneOverwhelmingException*_ can be moved into the exception package _*org.apache.cassandra.exceptions*_ that placed all classes about implementing possible exceptions.
Bug: Run utests_system_keyspace_directory with Java 11 in CircleCI
Status: Resolved
Priority: Normal
Resolution: Duplicate
Created: 30/May/22 14:17
Resolved: 24/Oct/22 13:49

Currently we run those tests only with Java 8, I have to dig into it further but it seems that there is no specific reason not to run those with Java 11 too.
Bug: Incremental repair leaks SomeRepairFailedException after switch away from flatMap
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 10/May/22 16:25
Resolved: 10/May/22 22:28

This is an extension of CASSANDRA-17549.

Incremental repair used to do a flatMap where it returned a failed future of SomeRepairFailedException; this would not trigger our failure logging to log it due to the fact the executor didn’t know about it and RepairRunnable knew to ignore that error, a change was made to use map and throw the exception, and later that behavior was updated to trigger uncaughtException handling which leaks this exception.

To roll back to previous behavior, we should switch back to flatMap to avoid this logging
Bug: Fix setters for native_transport_max_concurrent_requests_in_bytes and native_transport_max_concurrent_requests_in_bytes_per_ip 
Status: Open
Priority: Normal
Created: 02/Apr/22 01:54

While working on CASSANDRA-17341 we noticed that while native_transport_max_concurrent_requests_in_bytes and native_transport_max_concurrent_requests_in_bytes_per_ip  are checked for -1 during startup and have default value, this is not the case in their setters. 

We fixed this for trunk but those properties exist also in previous versions. We need to check those setters and probably to back port similar fix.

CC [~maedhroz] , [~dcapwell]  and [~mck]
Bug: Revert the removal and deprecate withBufferSizeInMB(int size) in favor of the new withBufferSizeInMiB(int size)
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 31/May/22 21:30
Resolved: 02/Jun/22 22:25

_withBufferSizeInMB(int size)_ was renamed in 4.1. 

The right way to do it was to deprecate it and add the new one _withBufferSizeInMiB(int size)_

Add back _withBufferSizeInMB(int size)_
Bug: netty vulnerable to CVE-2022-24823
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 17/May/22 10:35
Resolved: 18/May/22 15:15

{noformat}
Dependency-Check Failure:
One or more dependencies were identified with vulnerabilities that have a CVSS score greater than or equal to '1.0': 
netty-all-4.0.44.Final.jar: CVE-2022-24823
See the dependency-check report for more details.
{noformat}

We already have suppressions for 4.0.44 and I suspect this will be another but should be investigated.
Bug: Mention some undocumented behaviors of native protocol v5
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 24/May/22 20:42
Resolved: 26/May/22 07:38

[Patch as a GitHub PR to my own fork|https://github.com/whatyouhide/cassandra/pull/1]

Some things in the native protocol v5 are undocumented:
 * Integers in the outer framing format are little endian
 * There is no mention of the parameters used to tweak the CRC24 algorithm
 * No mention of the fact that if the uncompressed payload length in Section 2.2 is 0, then the "compressed payload" should not be decompressed
Bug: Test Failure: dtest.repair_tests.repair_test.TestRepair.test_dead_sync_participant (from Cassandra dtests)
Status: Resolved
Priority: Normal
Resolution: Duplicate
Created: 13/May/22 18:29
Resolved: 02/Jun/22 15:21

Flaked a couple times on 4.1
{code}
Error Message: test teardown failure
Unexpected error found in node logs (see stdout for full details). Errors: [[node2] 'WARN  [Streaming-EventLoop-4-2] 2022-05-11 11:56:25,064 DefaultChannelPipeline.java:1152 - An exceptionCaught() event was fired, and it reached at the tail of the pipeline. It usually means the last handler in the pipeline did not handle the exception.\nio.netty.channel.unix.Errors$NativeIoException: readAddress(..) failed: Connection reset by peer', [node2] 'WARN  [Streaming-EventLoop-4-3] 2022-05-11 11:56:25,064 DefaultChannelPipeline.java:1152 - An exceptionCaught() event was fired, and it reached at the tail of the pipeline. It usually means the last handler in the pipeline did not handle the exception.\nio.netty.channel.unix.Errors$NativeIoException: readAddress(..) failed: Connection reset by peer', [node2] 'WARN  [Streaming-EventLoop-4-1] 2022-05-11 11:56:25,064 DefaultChannelPipeline.java:1152 - An exceptionCaught() event was fired, and it reached at the tail of the pipeline. It usually means the last handler in the pipeline did not handle the exception.\nio.netty.channel.unix.Errors$NativeIoException: readAddress(..) failed: Connection reset by peer']
{code}
https://ci-cassandra.apache.org/job/Cassandra-4.1/14/testReport/dtest.repair_tests.repair_test/TestRepair/test_dead_sync_participant/

Nightlies archive if above is dropped: https://nightlies.apache.org/cassandra/ci-cassandra.apache.org/job/Cassandra-4.1/14/testReport/dtest.repair_tests.repair_test/TestRepair/test_dead_sync_participant/
Bug: Fix flaky tests in TopPartitionsTest
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 20/May/22 21:04
Resolved: 20/Jul/22 22:11

While working on other tickets we noticed a few tests from TopPartitionTest are flaky on 4.1. 

Example run with the CircleCI multiplexer: [https://app.circleci.com/pipelines/github/adelapena/cassandra?branch=flaky_top_partitions_test_4.1&filter=all]

I haven't seen those in Jenkins though.
Bug: Remove javadocs step from CI and release process
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 23/Jun/22 05:16
Resolved: 18/Aug/22 11:01

Currently the javadocs step is both:
- Taking up jenkins cycles and generating a [large output|https://ci-cassandra.apache.org/job/Cassandra-trunk-artifacts/1313/jdk=jdk_1.8_latest,label=cassandra/consoleFull] in CI when building artifacts
- Failing randomly on javadoc issues such as {{AlterTableStatement.java:135: error: text not allowed in element}}

Apidocs are not being bundled, uploaded or used anywhere. Hence it would be best to remove javadocs generation on every CI. Mainly removing javadoc from artifacts and mvn-install.
Bug: Fix flaky dtest - org.apache.cassandra.distributed.test.SchemaTest.readRepair
Status: Resolved
Priority: Normal
Resolution: Duplicate
Created: 19/May/22 16:16
Resolved: 01/Jul/22 05:19

{code}
org.apache.cassandra.distributed.shared.ShutdownException: Uncaught exceptions were thrown during test
	at org.apache.cassandra.distributed.impl.AbstractCluster.checkAndResetUncaughtExceptions(AbstractCluster.java:1056)
	at org.apache.cassandra.distributed.impl.AbstractCluster.close(AbstractCluster.java:1042)
	at org.apache.cassandra.distributed.test.SchemaTest.readRepair(SchemaTest.java:46)
	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)
	Suppressed: java.lang.RuntimeException: java.lang.AssertionError
		at org.apache.cassandra.net.InboundSink.accept(InboundSink.java:108)
		at org.apache.cassandra.distributed.impl.Instance.lambda$receiveMessageRunnable$6(Instance.java:495)
		at org.apache.cassandra.concurrent.ExecutionFailure$1.run(ExecutionFailure.java:124)
		at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:120)
		at io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
		at java.base/java.lang.Thread.run(Thread.java:829)
	Caused by: java.lang.AssertionError
		at org.apache.cassandra.locator.TokenMetadata.firstTokenIndex(TokenMetadata.java:1171)
		at org.apache.cassandra.locator.TokenMetadata.firstToken(TokenMetadata.java:1185)
		at org.apache.cassandra.locator.AbstractReplicationStrategy.getNaturalReplicas(AbstractReplicationStrategy.java:95)
		at org.apache.cassandra.locator.AbstractReplicationStrategy.getLocalReplicaFor(AbstractReplicationStrategy.java:111)
		at org.apache.cassandra.db.ReadCommandVerbHandler.validateTransientStatus(ReadCommandVerbHandler.java:108)
		at org.apache.cassandra.db.ReadCommandVerbHandler.doVerb(ReadCommandVerbHandler.java:50)
		at org.apache.cassandra.net.InboundSink.lambda$new$0(InboundSink.java:78)
		at org.apache.cassandra.net.InboundSink.accept(InboundSink.java:97)
{code}

https://ci-cassandra.apache.org/job/Cassandra-4.1/28/testReport/org.apache.cassandra.distributed.test/SchemaTest/readRepair/
Bug: CQL.textile needs to be made current
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 22/Jun/22 11:18
Resolved: 28/Sep/22 14:07

Per CASSANDRA-17570 https://github.com/apache/cassandra/blob/trunk/doc/cql3/CQL.textile is outdated, and the document we ship inside packages, so this should be made current.
Bug: Fix flaky test - org.apache.cassandra.distributed.test.repair.ForceRepairTest.force
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 20/Apr/22 15:38
Resolved: 07/Jun/22 10:47

Seen on jenkins here: [https://ci-cassandra.apache.org/job/Cassandra-trunk/1083/testReport/org.apache.cassandra.distributed.test.repair/ForceRepairTest/force_2/]

 

and circle here:

https://app.circleci.com/pipelines/github/driftx/cassandra/440/workflows/42f936c7-2ede-4fbf-957c-5fb4e461dd90/jobs/5160/tests#failed-test-1

{noformat}
junit.framework.AssertionFailedError: nodetool command [repair, distributed_test_keyspace, --force, --full] was not successful
stdout:
[2022-04-20 15:11:01,402] Starting repair command #2 (1701a090-c0bc-11ec-9898-07c796ce6a49), repairing keyspace distributed_test_keyspace with repair options (parallelism: parallel, primary range: false, incremental: false, job threads: 1, ColumnFamilies: [], dataCenters: [], hosts: [], previewKind: NONE, # of ranges: 3, pull repair: false, force repair: true, optimise streams: false, ignore unreplicated keyspaces: false, repairPaxos: true, paxosOnly: false)
[2022-04-20 15:11:11,406] Repair command #2 failed with error Did not get replies from all endpoints.
[2022-04-20 15:11:11,408] Repair command #2 finished with error

stderr:
error: Repair job has failed with the error message: Repair command #2 failed with error Did not get replies from all endpoints.. Check the logs on the repair participants for further details
-- StackTrace --
java.lang.RuntimeException: Repair job has failed with the error message: Repair command #2 failed with error Did not get replies from all endpoints.. Check the logs on the repair participants for further details
	at org.apache.cassandra.tools.RepairRunner.progress(RepairRunner.java:137)
	at org.apache.cassandra.utils.progress.jmx.JMXNotificationProgressListener.handleNotification(JMXNotificationProgressListener.java:77)
	at javax.management.NotificationBroadcasterSupport.handleNotification(NotificationBroadcasterSupport.java:275)
	at javax.management.NotificationBroadcasterSupport$SendNotifJob.run(NotificationBroadcasterSupport.java:352)
	at org.apache.cassandra.concurrent.ExecutionFailure$1.run(ExecutionFailure.java:124)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
	at io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
	at java.lang.Thread.run(Thread.java:748)
{noformat}
Bug: Fix test org.apache.cassandra.distributed.test.PaxosRepairTest#paxosRepairVersionGate
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 21/Apr/22 18:39
Resolved: 12/Sep/22 13:10

https://app.circleci.com/pipelines/github/dcapwell/cassandra/1381/workflows/4a4e6100-6582-43fd-8f39-6b3cbb5a94b6/jobs/11282/tests#failed-test-0

{code}
junit.framework.AssertionFailedError: Repair failed with errors: [Repair session aa00ae00-c192-11ec-89f5-d521036fedec for range [(000000c8,0000012c], (00000064,000000c8], (0000012c,00000064]] failed with error Paxos cleanup session a1fe1fea-7522-47ec-879a-7f2e6cc592ad failed on /127.0.0.3:7012 with message: Unsupported peer versions for a6404aa0-c192-11ec-89f5-d521036fedec [(000000c8,0000012c], (00000064,000000c8], (0000012c,00000064]], Repair command #3 finished with error]
	at org.apache.cassandra.distributed.test.PaxosRepairTest.lambda$repair$54f7d7c2$1(PaxosRepairTest.java:189)
	at org.apache.cassandra.concurrent.FutureTask$1.call(FutureTask.java:81)
	at org.apache.cassandra.concurrent.FutureTask.call(FutureTask.java:47)
	at org.apache.cassandra.concurrent.FutureTask.run(FutureTask.java:57)
	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
	at io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
	at java.base/java.lang.Thread.run(Thread.java:834)
{code}