av9ash/GitBugs huggingface dataset:
Bug: Fix test/distributed/org/apache/cassandra/distributed/test/IncRepairCoordinatorErrorTest
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 19/Aug/22 21:39
Resolved: 22/Aug/22 17:19

test/distributed/org/apache/cassandra/distributed/test/IncRepairCoordinatorErrorTest

needs to be fixed on 4.1 and trunk

[https://app.circleci.com/pipelines/github/yifan-c/cassandra/394/workflows/0079ce49-a851-4bf9-b6cd-3f9b76e9667c/jobs/3786/tests#failed-test-0]
{code:java}
java.lang.ClassCastException: class org.apache.cassandra.utils.TimeUUID cannot be cast to class java.util.UUID (org.apache.cassandra.utils.TimeUUID is in unnamed module of loader 'app'; java.util.UUID is in module java.base of loader 'bootstrap') at org.apache.cassandra.distributed.test.IncRepairCoordinatorErrorTest.errorTest(IncRepairCoordinatorErrorTest.java:50) 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: Flaky DescribeStatementTest
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 11/Aug/22 08:00
Resolved: 16/Aug/22 07:46

Jenkins is showing DescribeStatementTest falking:

{noformat}
Regression

org.apache.cassandra.cql3.statements.DescribeStatementTest.testDescribeFunctionAndAggregate
Failing for the past 1 build (Since
#127 )
Took 0.94 sec.
Failed 1 times in the last 28 runs. Flakiness: 3%, Stability: 96%
Error Message

Invalid value for row 0 column 2 (name of type varchar), expected <'function_07()'> (13 bytes) but got <'function_06(tuple<int>, list<frozen<tuple<int, text>>>, tuple<frozen<tuple<int, text>>, text>)'> (94 bytes) (using protocol version 5/v5)

Stacktrace

junit.framework.AssertionFailedError: Invalid value for row 0 column 2 (name of type varchar), expected <'function_07()'> (13 bytes) but got <'function_06(tuple<int>, list<frozen<tuple<int, text>>>, tuple<frozen<tuple<int, text>>, text>)'> (94 bytes) (using protocol version 5/v5)
	at org.apache.cassandra.cql3.CQLTester.assertRowsNet(CQLTester.java:1405)
	at org.apache.cassandra.cql3.CQLTester.assertRowsNet(CQLTester.java:1365)
	at org.apache.cassandra.cql3.statements.DescribeStatementTest.testDescribeFunctionAndAggregate(DescribeStatementTest.java:132)
{noformat}
Bug: flaky dtest-upgrade.upgrade_tests.compatibility_flag_test.TestCompatibilityFlag.test__compatibility_flag_on_3014
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 12/Jul/22 08:29
Resolved: 14/Jul/22 05:12

I noticed while working on other ticket the following failure

{noformat}
Regression

dtest-upgrade.upgrade_tests.compatibility_flag_test.TestCompatibilityFlag.test__compatibility_flag_on_3014 (from Cassandra dtests)
Failing for the past 1 build (Since
#1822 )
Took 29 sec.
Error Message

AssertionError: Expected {'0eff4047039accb22e83e048f45faaf497f7dbeeb9b7b263ee57e80115c15f20': ['1', '2', '3'], '4e4f0c52c483f4ebca82d4784c569a2e88cc89d417b1106d3166d8dade6a6dc5': ['2', '3', '4'], 'a5d7d00fe13de614673feb05b0f423da60659f481a4248a8f86a63f4ad82da1c': ['3', '4', '5'], '3a177d1a82c9b49287f02e567526347993d756c84ed6a2d4571b901b17a21e72': ['4', '5', '6'], '8aa7cf7ad64690bd7053ffff36b8d5b430b27193b0d163e26c4c427550e6ca54': ['5', '6', '7']} from SELECT * FROM test.test, but got {'3a177d1a82c9b49287f02e567526347993d756c84ed6a2d4571b901b17a21e72': ['4', '5', '6'], 'a5d7d00fe13de614673feb05b0f423da60659f481a4248a8f86a63f4ad82da1c': ['3', '4', '5'], '4e4f0c52c483f4ebca82d4784c569a2e88cc89d417b1106d3166d8dade6a6dc5': ['2', '3', '4'], '0eff4047039accb22e83e048f45faaf497f7dbeeb9b7b263ee57e80115c15f20': ['1', '2', '3']}
{noformat}
Bug: It is not possible to autocomplete "WITH" when creating materialized view
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 07/Sep/22 14:42
Resolved: 04/Oct/22 19:22

I noticed that when I type this:

{code}
CREATE MATERIALIZED VIEW ks.mv2 AS SELECT * FROM t WHERE k IS NOT NULL AND c1 IS NOT NULL AND c2 IS NOT NULL PRIMARY KEY (c1,k,c2) <TAB>
{code}

nothing happens after pressing tab, there should be options shown as for table case.
Bug: Skip sstable startup checks for dropped system tables
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 26/Jul/22 17:16
Resolved: 05/Aug/22 12:03

In CASSANDRA-8049 we changed our behavior to explicitly not startup while iterating over the whole data file directory before loading schema. In the case where you have (admittedly _very)_ old files left around from dropped system tables from old C* versions (think 1.0 era), you can end up with clusters that won't start due to what was, at the time, normal operations.

We should change from hard killing nodes to instead warn operators they have leftovers of old system tables that need to be cleaned up. Ideally these files would be manually removed by operators before the upgrade to new versions however we can't always rely on this so killing nodes on startup for this specific case is suboptimal. We certainly still need to log the found files to give operators an indication of what needs to be cleaned up.

While we can't load the schema to make sure all directories are safe, we _can_ know which tables exist in the system keyspace so we should be able to safely modify this startup check to log rather than kill for system tables only.
Bug: CEP-20: Dynamic Data Masking
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 30/Sep/22 11:04
Resolved: 24/Mar/23 14:10

Implementation of dynamic data masking as described in [CEP-20|https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-20%3A+Dynamic+Data+Masking].

Dynamic data masking (DDM) allows to obscure sensitive information while still allowing access to the masked columns, and without changing the stored data. The CEP aims to provide DDM for Apache Cassandra using both native and user-defined CQL functions. These functions can be either be used on their own or be attached to specific columns in the table definition.
Bug: Fix upgrade test test_collection_function on trunk
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 15/Aug/22 22:16
Resolved: 16/Aug/22 17:21

The upgrade test  test_collection_functio is failing on trunk post CASSANDRA-8877

For unknown to me reason Jenkins shows it started failing post 

CASSANDRA-17575 which does not make sense as that ticket improved documentation.

Bisecting in Circle CI points to CASSANDRA-8877

The test run in a loop before CASSANDRA-8877 [passes|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/1863/workflows/dea8966b-25f2-48e5-b451-b257d1a7242d] , it consistently fails with CASSANDRA-8877 [commit|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/1864/workflows/01bbc009-9160-4595-97e2-a2f657fd0798/jobs/14587/steps].

CC [~adelapena], [~ycai] and [~b.lerer@gmail.com]
Bug: Out of range exception on column index downsampling
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 19/Aug/22 17:06
Resolved: 23/Aug/22 16:22

We've seen a histogram overflow exception in the wild; an IllegalArgumentException w/{{{}Out of range{}}} on {{{}Ints.checkedCast{}}}. Looks like we need to tune the {{defaultPartitionSizeHistogram}} a bit and be more graceful about handling and degrading gracefully in {{SegmentedFile}}
Bug: Harden parsing of boolean values in CQL in PropertyDefinitions
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 07/Sep/22 14:18
Resolved: 11/Nov/22 14:38

There is currently this in PropertyDefinitions class as a pattern we use for testing a boolean value in cqlsh

{code}
private static final Pattern PATTERN_POSITIVE = Pattern.compile("(1|true|yes)");
{code}

This might be source of mistakes and typos. For example, if a user does, for example:

{code}
ALTER TABLE ks.tb WITH cdc = tru;
{code}

If he does not notice it, he thinks that cdc is true, but it is not. 

More to it, currently, everything which is not "1", "true", or "yes" is evaluated as false. We should harden this in such a way that both logical true and false would be parsed only on well defined values and every other value would be rejected and a query would fail.

EDIT: I have checked how it behaves in cqlsh and there seems to be validation of this already like this:

{code}
cqlsh> ALTER TABLE abc.def WITH cdc = tru;
SyntaxException: line 1:31 no viable alternative at input 'tru' (ALTER TABLE abc.def WITH [cdc] =...)
{code}

It seems that cqlsh already knows this should be a boolean and rejects such query.

Nevertheless, it is still reasonable to harden this on the code level when a query is executed in Java, programmatically (e.g. as part of tests or similar). The patch also includes optimizations to not return Boolean but boolean on related methods (other primitives are covered as well).
Bug: Clean stderr in output from InvalidatePermissionsCacheTest
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 12/Aug/22 16:39
Resolved: 16/Aug/22 15:27

We use {{tool.getStderr}} in {{InvalidatePermissionsCacheTest}} which can make the tests fail if you happen to be running with anything in your {{{}JAVA_TOOL_OPTIONS{}}}.
Bug: nodetool/rebuild: Add flag to exclude nodes from local datacenter
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 31/Aug/22 00:06
Resolved: 18/Nov/22 07:06

During expansion by Dc, when we issue nodetool/rebuild from new dc to rebuild the data from other DCs. If src-dc is not passed explicitly, then C* tries to rebuild the data from the same (new dc) dc. 

We don’t exclude other nodes in the same DC. Only down sources and the local node itself are excluded.
```
 // We're _always_ filtering out a local node and down sources
        addSourceFilter(new RangeStreamer.FailureDetectorSourceFilter(failureDetector));
        addSourceFilter(new RangeStreamer.ExcludeLocalNodeFilter());
```

We should fix nodetool/rebuild to exclude the local DC (from where we’re executing the command) while issuing nodetool/rebuild without passing src dc

 

Example:
in a 3 DC cluster, 
ks1 has DC1, DC2
ks2 has DC1, DC2, DC3
ks3 has DC2

now, we add a new DC [DC4] and configured it to all 3 keyspaces.

if we run rebuild with src DC as DC1, ks3 will fail as it does not have DC1. 

Now, without src DC, the expectation is rebuild would auto pick up DCs for each keyspace (let's say ks1: DC1, ks2: DC1, ks3: DC2) and would never fail due to under-replicated keyspaces.

The issue with this approach (without src dc) is that, DC4 is getting picked up during rebuild (as src), but DC4 does not have any data yet!

so, with the patch (ignore local dc flag), DC4 can be filtered out and let the database pick up the right dc for each keyspace [from existing 3 DCs]. 
  -- this is what is the expectation after the patch.
Bug: Fix CQL aggregation functions for collections, tuples and UDTs
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 11/Aug/22 16:37
Resolved: 18/Nov/22 10:39

It has been found during CASSANDRA-8877 that CQLS's aggregation functions {{{}max{}}}, {{min}} and {{count}} can be applied to collections, but the result is returned as a blob. For example:
{code:java}
CREATE TABLE t (k int PRIMARY KEY, l list<int>);
INSERT INTO t(k, l) VALUES (0, [1, 2, 3]);
INSERT INTO t(k, l) VALUES (1, [10, 20, 30]);
SELECT max(l) FROM t;

 system.max(l)
------------------------------------------------------------
 0x00000003000000040000000a0000000400000014000000040000001e
{code}
This happens on 3.0, 3.11, 4.0, 4.1 and trunk.

I'm not sure on whether the function shouldn't be supported for collections, or it should be supported but the result is wrong.

In the example above, the returned blob is the serialized value of {{{}[10, 20, 30]{}}}, which is the right one according to the list comparator. I think this happens because the matched version of the function is the one for {{{}(blob) -> blob{}}}. We would need a {{(list<int>) -> list<int>}} function instead, but this function doesn't exist.

It would be quite easy to add versions of the {{{}max{}}}, {{min}} and {{count}} functions for every type of collection ({{{}list<int>{}}}, {{{}list<text>{}}}, {{{}map<int, int>{}}}, {{{}map<int, text>{}}}, etc.). The downside of this approach is that it would increase the number of aggregation functions kept in memory from 82 to 2722, if my maths are right. This is quite an increase, mainly due to the many possible combinations of the {{map}} type. [Here|https://github.com/adelapena/cassandra/commit/e3ba3c2dc36ce58d06942078c708ffb93eb3cd84] is a quick, incomplete prototype of the approach.

Also, I'm not sure that applying those aggregation functions to collections is very useful in practice. Thus, an alternative approach would be just forbidding them, considering them not supported. I don't think it would be a problem for backward compatibility since no one has complained about the current behaviour, and we might well consider that the original intent was not to allow aggregation on collections. At least, there aren't any tests for it, and I can't find any documentation about it either.

Another idea that comes to mind is that we could change the meaning of those functions to aggregate the values within the collection, instead of aggregating the rows. In that case, the behaviour would be:
{code:java}
CREATE TABLE t (k int PRIMARY KEY, l list<int>);
INSERT INTO t(k, l) VALUES (0, [1, 2, 3]);
INSERT INTO t(k, l) VALUES (1, [10, 20, 30]);
SELECT max(l) FROM t;

 k | system.max(l)
---+-----------
 1 | 30
 0 | 3
{code}
Of course we could have separate function names for that type of collection aggregations, like {{{}collectionMax{}}}, {{{}maxItem{}}}, or something like that.
Bug: Fix Python DTest replace_address_test.TestReplaceAddress.test_replace_active_node
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 22/Aug/22 15:24
Resolved: 22/Aug/22 21:44

h4. replace_address_test.TestReplaceAddress.test_replace_active_node is failing after CASSANDRA-17805 on trunk. 
{code:java}
Error Message
test teardown failure

Stacktrace
Unexpected error found in node logs (see stdout for full details). Errors: [[replacement] 'ERROR [main] 2022-08-16 00:38:01,101 StorageService.java:1871 - Unable to replace node for token=-1586450498160569396. The node is reporting as alive with updateTimestamp=2512188286649176, allowedDelay=2512179515884926']
{code}
[https://ci-cassandra.apache.org/job/Cassandra-trunk/1270/testReport/dtest-large.replace_address_test/TestReplaceAddress/test_replace_active_node]
Bug: Implement SSTable count by TWCS bucket
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 25/Jul/22 15:48
Resolved: 01/Aug/22 18:23

It should be possible to report the total number of sstables in buckets by using a JMX call {{getSSTableCountPerTWCSBucket()}}, similarly to {{getSSTableCountPerLevel()}}. This will help us to assert the compaction strategy is able to keep up with major compactions on older time buckets.
Bug: NPE in org.apache.cassandra.cql3.Attributes.getTimeToLive
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 16/Aug/22 19:16
Resolved: 17/Aug/22 21:22

{code}
java.lang.NullPointerException
at org.apache.cassandra.cql3.Attributes.getTimeToLive(Attributes.java:129)
       at org.apache.cassandra.cql3.statements.ModificationStatement.getTimeToLive(ModificationStatement.java:237)
       at org.apache.cassandra.cql3.statements.ModificationStatement.makeUpdateParameters(ModificationStatement.java:833)
       at org.apache.cassandra.cql3.statements.ModificationStatement.makeUpdateParameters(ModificationStatement.java:799)
       at org.apache.cassandra.cql3.statements.ModificationStatement.addUpdates(ModificationStatement.java:736)
       at org.apache.cassandra.cql3.statements.ModificationStatement.getMutations(ModificationStatement.java:689)
       at org.apache.cassandra.cql3.statements.ModificationStatement.executeWithoutCondition(ModificationStatement.java:470)
       at org.apache.cassandra.cql3.statements.ModificationStatement.execute(ModificationStatement.java:454)
       at org.apache.cassandra.cql3.QueryProcessor.processStatement(QueryProcessor.java:255)
       at org.apache.cassandra.cql3.QueryProcessor.processPrepared(QueryProcessor.java:716)
       at org.apache.cassandra.cql3.QueryProcessor.processPrepared(QueryProcessor.java:678)
       at org.apache.cassandra.transport.messages.ExecuteMessage.execute(ExecuteMessage.java:160)
       at org.apache.cassandra.transport.Message$Request.execute(Message.java:242)
       at org.apache.cassandra.transport.Dispatcher.processRequest(Dispatcher.java:142)
       at org.apache.cassandra.transport.Dispatcher.processRequest(Dispatcher.java:158)
       at org.apache.cassandra.transport.Dispatcher.processRequest(Dispatcher.java:181)
       at org.apache.cassandra.transport.Dispatcher.lambda$dispatch$1(Dispatcher.java:108)
       at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
       at org.apache.cassandra.concurrent.AbstractLocalAwareExecutorService$FutureTask.run(AbstractLocalAwareExecutorService.java:162)
       at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:119)
       at io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
       at java.base/java.lang.Thread.run(Thread.java:834)
{code}
Bug: Compaction NullPointerException when changing neverPurgeTombstones from true to false
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 14/Sep/22 19:01
Resolved: 19/Sep/22 16:09

When changing neverPurgeTombstones from true to false we have a few fields in CompactionController nulled out; this means that ongoing compactions might get exceptions.

This is a pretty infrequent edge case so ok putting this trunk only and back-porting if someone runs into it on other versions.
Bug: Update debian packages for bullseye
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 31/Aug/22 13:11
Resolved: 03/Nov/22 13:30

We are updating the buster docker image used to build debian packages to bullseye (which is probably a bit overdue) in CASSANDRA-17854 Package build dependencies for versions using python2 need to be updated for this to work.
Bug: Test Failure: org.apache.cassandra.transport.RateLimitingTest.shouldThrowOnOverloadSmallMessages[4/v4]-cdc 
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 27/Sep/22 15:20
Resolved: 05/Oct/22 19:24

[Link|https://ci-cassandra.apache.org/job/Cassandra-4.1/169/testReport/org.apache.cassandra.transport/RateLimitingTest/shouldThrowOnOverloadSmallMessages_4_v4__cdc/]

Failed 1 times in the last 30 runs. Flakiness: 6%, Stability: 96%

Error Message
expected:<0> but was:<316>

StackTrace
{code:java}
junit.framework.AssertionFailedError: expected:<0> but was:<316>
	at org.apache.cassandra.transport.RateLimitingTest.testOverload(RateLimitingTest.java:198)
	at org.apache.cassandra.transport.RateLimitingTest.shouldThrowOnOverloadSmallMessages(RateLimitingTest.java:111)
	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: RPM noboolean packages deployed in place of others
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 08/Sep/22 15:32
Resolved: 27/Sep/22 13:10

In CASSANDRA-17765 we created the 'noboolean' packages for distros unable to understand boolean dependency logic, but it appears these are the only packages deployed for download - once as noboolean packages, and once as standard packages.
Bug: When doing a host replacement, we need to check that the node is a live node before failing with "Cannot replace a live node..."
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 05/Aug/22 20:23
Resolved: 15/Aug/22 21:24

Currently, during a node replacement, we check that the node has not updated gossip for a configured {{ring_delay}} amount of time (defaults to 30 seconds). If we see an update from the node that we are replacing in less than the configured time, we throw a {{UnsupportedOperationException}} with message {{Cannot replace a live node...}}. However, we never check whether the node is reporting as alive or not alive.

We need an additional check to ensure that the node being replaced is reported as live; and only then throw the {{UnsupportedOperationException}}
Bug: AutoSnapshotTtlTest#testAutoSnapshotTTlOnDropAfterRestart fails sporadically on missing stdout contents
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 05/Aug/22 20:18
Resolved: 31/Aug/22 11:44

See [https://app.circleci.com/pipelines/github/maedhroz/cassandra/487/workflows/0ad42210-2979-4c5d-a4e8-d8cedf9285a7/jobs/4686/tests#failed-test-0]
 
My guess is that in some resource constrained environment, even the first {{nodeool listsnapshots}} invocation doesn’t have “dropped” in the stdout. In other words, we skip to the state of the world the last assertion in the test is checking.
Bug: NPE bug in streaming checking if SSTable is being repaired
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 05/Aug/22 00:45
Resolved: 08/Aug/22 20:54

Streaming hit a race condition where a SSTable was being repaired, but the moment we try to check the repair ID the repair was over

{code}
java.lang.NullPointerException
at org.apache.cassandra.db.streaming.CassandraStreamManager.lambda$null$0(CassandraStreamManager.java:110)
at com.google.common.collect.Iterators$5.computeNext(Iterators.java:639)
at com.google.common.collect.AbstractIterator.tryToComputeNext(AbstractIterator.java:141)
at com.google.common.collect.AbstractIterator.hasNext(AbstractIterator.java:136)
at org.apache.cassandra.db.streaming.CassandraStreamManager.lambda$createOutgoingStreams$1(CassandraStreamManager.java:121)
at org.apache.cassandra.db.ColumnFamilyStore.select(ColumnFamilyStore.java:2000)
at org.apache.cassandra.db.ColumnFamilyStore.selectAndReference(ColumnFamilyStore.java:1976)
at org.apache.cassandra.db.streaming.CassandraStreamManager.createOutgoingStreams(CassandraStreamManager.java:96)
at org.apache.cassandra.streaming.StreamSession.getOutgoingStreamsForRanges(StreamSession.java:481)
at org.apache.cassandra.streaming.StreamSession.addTransferRanges(StreamSession.java:440)
at org.apache.cassandra.streaming.StreamSession.lambda$null$6(StreamSession.java:816)
at java.base/java.lang.Iterable.forEach(Iterable.java:75)
at org.apache.cassandra.streaming.StreamSession.lambda$processStreamRequests$7(StreamSession.java:812)
at java.base/java.util.Map.forEach(Map.java:661)
at org.apache.cassandra.streaming.StreamSession.processStreamRequests(StreamSession.java:808)
at org.apache.cassandra.streaming.StreamSession.prepareAsync(StreamSession.java:740)
at org.apache.cassandra.streaming.StreamSession.lambda$prepare$3(StreamSession.java:720)
at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
at java.base/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:304)
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}