av9ash/GitBugs huggingface dataset:
Bug: Stream processing for SimpleRestriction::bindAndGetClusteringElements
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 04/Jun/24 20:53
Resolved: 06/Jun/24 15:31

Part 2 (of 2) of low-hanging fruit Stream performance improvements.

The second main Stream contributor to allocations and CPU was SimpleRestriction::bindAndGetClusteringElements, which contributes to 5% of all allocations for a 50/50 workload. The image attached shows allocation profiling on _trunk_ (see purple highlighted sections for Stream-related allocs).

The 'after' profile for a 50/50 workload shows a reduction from 4.58% allocations down to 1.37%. For a 90/10 (w/r) workload we see 4.28% decrease to 1.10%.
Bug: ALTER KEYSPACE should cleanup available_ranges_v2 when removing a DC
Status: Triage Needed
Priority: Normal
Created: 05/Jun/24 21:51

The scenario:

New DC is added

Data is replicated to new DC for keyspace "mykeyspace" via a rebuild

DC is dropped in replication

DC is re-added to "mykeyspace"

When this happens, the user is unable to rebuild as available_ranges_v2 thinks it's unnecessary.  

We should remove mykeyspace from system.available_ranges_v2 when removing a DC.

Found in 4.1
Bug: Debian repository is missing 3.11.17 package
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 05/Jun/24 02:33
Resolved: 05/Jun/24 13:54

The Debian package for Cassandra 3.11.17 is missing from the JFrog artifactory. The [package index|https://apache.jfrog.io/artifactory/cassandra-deb/dists/311x/main/binary-amd64/Packages] is still referencing version 3.11.16:

{code}
Package: cassandra
Version: 3.11.16
...
Filename: pool/main/c/cassandra/cassandra_3.11.16_all.deb
...

Package: cassandra-tools
Source: cassandra
Version: 3.11.16
...
Filename: pool/main/c/cassandra/cassandra-tools_3.11.16_all.deb
...
{code}

When I tried to install the latest C* 3.11 version on Ubuntu, 3.11.16 got installed instead of 3.11.17.

Note that this was originally reported by [Roman on Stack Exchange|https://dba.stackexchange.com/questions/340007/].
Bug: Support for netty-tcnative 2.0.62+
Status: Triage Needed
Priority: Normal
Created: 23/May/24 13:44

Hello,

Are there plans to support netty-tcnative in version 2.0.62? Current version 2.0.36 does not work with openssl3.x. Motivation is that openssl 3.0.9+ is FIPS certified.

Currently i am able to replace library default boringSSL implementation with openssl by recompiling netty-tcnative but cassandra fails to load 2.0.62 regardless if it is compiled with 1.1.1 or 3.0.

Or is there other way to implement openssl3.x ?

Thank you
Bug: Update bundled Cassandra cassandra-driver-core dependency
Status: Triage Needed
Priority: Normal
Created: 22/May/24 06:01

There's a dependency in Cassandra project on an old version of the Java driver cassandra-driver-core - 3.11.0 in the 4.0 and later releases of Cassandra 

 

(For example on the 4.1 branch [https://github.com/apache/cassandra/blob/cassandra-4.1/build.xml#L691)] 

 

It appears that this dependency may have some security vulnerabilities in transitive dependencies.

But also this is a very old version of the driver, ideally it would be aligned to a newer version, I would suggest either 3.11.5 which is the latest in that line of driver versions [https://mvnrepository.com/artifact/com.datastax.cassandra/cassandra-driver-core|https://mvnrepository.com/artifact/com.datastax.cassandra/cassandra-driver-core)]

or this gets updated to the latest 4.x driver (as of writing that's 4.18.1 in [https://mvnrepository.com/artifact/org.apache.cassandra/java-driver-core] ) but this seems like a larger undertaking.
Bug: Expand CREATE TABLE CQL on a coordinating node before submitting to CMS
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 26/Apr/24 11:56
Resolved: 23/May/24 14:47

This is done to unblock CASSANDRA-12937 and allow preserving defaults with which the table was created between node bounces and between nodes with different configurations. For now, we are preserving 5.0 behaviour.
Bug: null values injected while drop compact storage was executed
Status: Triage Needed
Priority: Normal
Created: 23/May/24 10:53

We noticed that values of some inserts that were run in parallel to an alter table drop compact storage statement turned into null values.

This happened with version 3.11.10.

Since then, we upgraded to 3.11.17. We tried to write a reproducer (inserting millions of rows/columns in parallel to drop compact storage) but we were not able to reproduce the bug with 3.11.17.

This was reported on the mailing list first ([https://lists.apache.org/thread/hgwyd917yp01q0k9op79gztkx3qwypbc)] and seems to relate to https://issues.apache.org/jira/browse/CASSANDRA-13004.
Bug: ModificationStatement#casInternal leaks RowIterator
Status: Patch Available
Priority: Normal
Created: 08/May/24 14:20

In the `ModificationStatement` class, the `casInternal` method opens a row iterator without closing it, causing the iterator to leak resources. Here is a link to the relevant code in the `trunk` branch.

[https://github.com/apache/cassandra/blob/a77a2d10b1d247ed920b75df79f982a3b7c6a431/src/java/org/apache/cassandra/cql3/statements/ModificationStatement.java#L680-L684]

 

It seems that `cassandra-3.0.30` has the bug, but `cassandra-2.2.19` does not have it. Is it correct to target `cassandra-3.0.30`?

What is the best practice for testing this kind of bug fix? It seems like a low complexity fix. This is my first contribution to the Cassandra community, so any guidance is appreciated. Thanks!
Bug: Use more appropriate GC logging
Status: Triage Needed
Priority: Normal
Created: 22/May/24 16:40

Our GC default setting spam the gc log resulting in unnecessary IO, cpu usage, and makes them less effective to use with tools like GCEasy.  Here's some examples of what our defaults log:

{noformat}
[2024-05-22T09:14:45.558-0700][0.022s][11668][9219][trace] Trying to allocate at address 0x00000006c0000000 heap of size 0x100000000
[2024-05-22T09:14:45.559-0700][0.022s][11668][9219][debug] Running G1 PreTouch with 4 workers for 4 work units pre-touching 4294967296B.
[2024-05-22T09:23:33.653-0700][121.363s][12868][21251][trace] GC(15) | 255|0x00000007bf000000, 0x00000007bf000000, 0x00000007c0000000|  0%| F|  |TAMS 0x00000007bf000000, 0x00000007bf000000| Untracked
[2024-05-22T09:23:33.528-0700][121.238s][12868][21251][trace] GC(15) | 178|0x0000000772000000, 0x0000000773000000, 0x0000000773000000|100%| E|CS|TAMS 0x0000000772000000, 0x0000000772000000| Complete
[2024-05-22T09:24:01.731-0700][149.441s][12868][21251][debug] GC(16) Heap before GC invocations=16 (full 0): garbage-first heap   total 4194304K, used 1918824K [0x00000006c0000000, 0x00000007c0000000)
[2024-05-22T09:24:01.731-0700][149.441s][12868][21251][debug] GC(16)   region size 16384K, 108 young (1769472K), 3 survivors (49152K)
[2024-05-22T09:24:01.731-0700][149.441s][12868][21251][debug] GC(16)  Metaspace       used 63070K, capacity 65566K, committed 65680K, reserved 1105920K
[2024-05-22T09:24:01.731-0700][149.441s][12868][21251][debug] GC(16)   class space    used 7274K, capacity 8432K, committed 8448K, reserved 1048576K
{noformat}

Quickly looking at the breakdown of trace, debug, and info:

{noformat}
grep trace logs/gc.log | wc -l
    7771
grep debug logs/gc.log | wc -l
     188
grep info logs/gc.log | wc -l
    1065
{noformat}

In summary, we're seeing almost 9K worth of debug and trace log lines for every 1K of INFO, and the debug and trace doesn't have any value for a user that would leave it unset.  Really interested users might want this, but they should know how to enable it.

We should use the INFO settings by default: 

{noformat}
JVM_OPTS="$JVM_OPTS -Xlog:gc=info:file=${CASSANDRA_LOG_DIR}/gc.log:time,uptime,pid,tid,level:filecount=10,filesize=10485760"
{noformat}
Bug: Fix CCM for Cassandra 5.0 and add arg to the command line which let the user explicitly select JVM
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 15/May/24 08:50
Resolved: 20/May/24 08:35

CCM fails to select the right Java version for Cassandra 5 binary distribution.

There are also two additional changes proposed here:
 * add {{--jvm-version}} argument to let the user explicitly select Java version when starting a node from command line
 * fail if {{java}} command is available on the {{PATH}} and points to a different Java version than Java distribution defined in {{JAVA_HOME}} because there is no obvious way for the user to figure out which one is going to be used
Bug: add absurdfarce's gpg key to project's KEYS file
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 20/May/24 22:28
Resolved: 20/May/24 22:32

The patch adds my gpg public key to the project's KEYS file found at [https://dist.apache.org/repos/dist/release/cassandra/KEYS]

My gpg public key here has the fingerprint 
 498AAC354AA5CB36FAAB7608B6E83A2D2E447E56

References:
 - [https://www.apache.org/dev/release-signing#keys-policy]
 - [http://www.apache.org/legal/release-policy.html]
Bug: When jvm-dtest is shutting down an instance TCM retries block the shutdown causing the test to fail
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 02/Apr/24 20:20
Resolved: 18/Apr/24 14:06

org.apache.cassandra.distributed.test.log.RequestCurrentEpochTest#testRequestingPeerWatermarks

{code}
java.lang.RuntimeException: java.util.concurrent.TimeoutException
	 org.apache.cassandra.utils.Throwables.maybeFail(Throwables.java:79)
	 org.apache.cassandra.utils.FBUtilities.waitOnFutures(FBUtilities.java:540)
	 org.apache.cassandra.distributed.impl.AbstractCluster.close(AbstractCluster.java:1098)
	 org.apache.cassandra.distributed.test.log.RequestCurrentEpochTest.testRequestingPeerWatermarks(RequestCurrentEpochTest.java:77)
	 java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	 java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	 java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) Caused by: java.util.concurrent.TimeoutException
	 org.apache.cassandra.utils.concurrent.AbstractFuture.get(AbstractFuture.java:253)
	 org.apache.cassandra.utils.FBUtilities.waitOnFutures(FBUtilities.java:532) Suppressed: java.util.concurrent.TimeoutException
{code}

In debugger I found the blocked future and it was src/java/org/apache/cassandra/tcm/EpochAwareDebounce.java waiting on src/java/org/apache/cassandra/tcm/RemoteProcessor.java retries
Bug: Merge pre-existing schema with the system defined one during upgrade
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 03/May/24 08:23
Resolved: 06/May/24 07:07

When upgrading we should merge the pre-existing schema with the system-defined schema. For example, if a table was defined in 5.0 in system_distributed, but then removed from SystemDistributedKeyspace.java in 5.1 we should still be able to read it (until manually dropped).
Bug: Enforce contract for internal metrics naming
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 03/May/24 21:52
Resolved: 08/May/24 18:02

Metrics have their internal representation which uniquely identifies a particular metric name. The name is formed as {{<metric group>.<metric type>.<metric name>.<metric scope>}}. For some metrics, the scope includes a metric name that is not necessary for uniqueness, this can be simplified.

For example,

{code}
// AS IS
org.apache.cassandra.metrics.StorageAttachedIndex.BalancedTreeIntersectionEarlyExits.my_keyspace.my_table.ColumnQueryMetrics.BalancedTreeIntersectionEarlyExits

// TO BE
org.apache.cassandra.metrics.StorageAttachedIndex.BalancedTreeIntersectionEarlyExits.my_keyspace.my_table.ColumnQueryMetrics
{code}

The metrics are filtered based on knowledge of how they are formatted, so having a metric scope without a built-in metric name also simplifies the way we filter metrics.
Bug: deterministic token allocation combined with slow gossip propogation can lead to data loss
Status: Resolved
Priority: Normal
Resolution: Duplicate
Created: 17/May/24 22:27
Resolved: 17/May/24 22:52

I've seen several cases now where starting nodes within a somewhat short time window (about a minute) when using the default allocation tokens for RF leads to token conflicts.  Unfortunately this can easily go undetected with medium to large clusters.

When this happens, different nodes in the cluster will have different understandings of the topology of the cluster.  I've seen this go unnoticed in a production environment for several months, leading to data loss, data resurrection, and other odd behavior.

We should apply some randomness to the tokens to ensure that even in the case of 1 nodes starting at once, it's still unlikely that they will ever have a conflict.  Applying a random() value to the token value between - 2^8 and 2^8 makes this statistically very, very unlikely that we'll ever have a collision while also preserving the balance of token distribution in the ring.  In the case of 2 nodes starting at the same time, the operator will have weird token distribution instead of data loss.

 
{noformat}
INFO  [GossipStage:1] 2024-05-17 22:16:12,333 StorageService.java:3006 - Nodes /10.0.2.134:7000 and cassandra1/10.0.1.61:7000 have the same token -1938510198161598815. /10.0.2.134:7000 is the new owner
INFO  [GossipStage:1] 2024-05-17 22:16:12,333 StorageService.java:3006 - Nodes /10.0.2.134:7000 and cassandra1/10.0.1.61:7000 have the same token -3478858378222500629. /10.0.2.134:7000 is the new owner
INFO  [GossipStage:1] 2024-05-17 22:16:12,333 StorageService.java:3006 - Nodes /10.0.2.134:7000 and cassandra1/10.0.1.61:7000 have the same token 3562748272064835315. /10.0.2.134:7000 is the new owner
INFO  [GossipStage:1] 2024-05-17 22:16:12,333 StorageService.java:3006 - Nodes /10.0.2.134:7000 and cassandra1/10.0.1.61:7000 have the same token 8085185010613503278. /10.0.2.134:7000 is the new owner{noformat}
Bug: IndexOutOfBoundsException while serializing CommandsForKey
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 17/May/24 20:47
Resolved: 17/May/24 22:20

When serializing CommandsForKey we have a concept of “unmanaged” but tests didn’t cover this… when we have anything unmanaged we fail to serialize with a IndexOutOfBounds due to using the ValueAccessor API incorrectly
Bug: IndexOutOfBoundsException thrown executing query when bound parameters are missing 
Status: Triage Needed
Priority: Normal
Created: 17/May/24 20:48

I prepared a query and tried to execute it without binding the parameters and this exception was thrown.  I think we should do a better job of telling the user how they didn't pass enough params instead of throwing exceptions.

I prepared this query:
{noformat}
SELECT * from system.local  WHERE token(key) > ? AND token(key) < ?{noformat}
Here's the exception:

 
{noformat}
ERROR [Native-Transport-Requests-1] 2024-05-17 13:39:51,786 ErrorMessage.java:457 - Unexpected exception during request
java.lang.IndexOutOfBoundsException: null
    at java.base/java.nio.Buffer.checkIndex(Buffer.java:693)
    at java.base/java.nio.HeapByteBuffer.getLong(HeapByteBuffer.java:458)
    at org.apache.cassandra.utils.ByteBufferUtil.toLong(ByteBufferUtil.java:505)
    at org.apache.cassandra.dht.Murmur3Partitioner$2.fromByteArray(Murmur3Partitioner.java:376)
    at org.apache.cassandra.cql3.restrictions.StatementRestrictions.getTokenBound(StatementRestrictions.java:913)
    at org.apache.cassandra.cql3.restrictions.StatementRestrictions.getPartitionKeyBoundsForTokenRestrictions(StatementRestrictions.java:879)
    at org.apache.cassandra.cql3.restrictions.StatementRestrictions.getPartitionKeyBounds(StatementRestrictions.java:841)
    at org.apache.cassandra.cql3.statements.SelectStatement.getRangeCommand(SelectStatement.java:793)
    at org.apache.cassandra.cql3.statements.SelectStatement.getQuery(SelectStatement.java:408)
    at org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:332)
    at org.apache.cassandra.cql3.statements.SelectStatement.execute(SelectStatement.java:108)
    at org.apache.cassandra.cql3.QueryProcessor.processStatement(QueryProcessor.java:256)
    at org.apache.cassandra.cql3.QueryProcessor.processPrepared(QueryProcessor.java:823)
    at org.apache.cassandra.cql3.QueryProcessor.processPrepared(QueryProcessor.java:801)
    at org.apache.cassandra.transport.messages.ExecuteMessage.execute(ExecuteMessage.java:167)
    at org.apache.cassandra.transport.Message$Request.execute(Message.java:256)
    at org.apache.cassandra.transport.Dispatcher.processRequest(Dispatcher.java:194)
    at org.apache.cassandra.transport.Dispatcher.processRequest(Dispatcher.java:213)
    at org.apache.cassandra.transport.Dispatcher.processRequest(Dispatcher.java:240)
    at org.apache.cassandra.transport.Dispatcher$RequestProcessor.run(Dispatcher.java:137)
    at org.apache.cassandra.concurrent.FutureTask$1.call(FutureTask.java:96)
    at org.apache.cassandra.concurrent.FutureTask.call(FutureTask.java:61)
    at org.apache.cassandra.concurrent.FutureTask.run(FutureTask.java:71)
    at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:143)
    at io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
    at java.base/java.lang.Thread.run(Thread.java:829){noformat}
Found in cassandra-5.0 branch, not sure how far back it goes.
Bug: Remove unused config params for out of range token requests
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 30/Apr/24 08:01
Resolved: 16/May/24 07:25

The fields {{log_out_of_token_range_requests}} and {{reject_out_of_token_range_requests}} in {{Config.java}} have never actually been used and are just vestiges from early development on CEP-21. 
We should remove them and the related accessors in {{DatabaseDescriptor}}.
Bug: Accord: Need to simulate Cassandra Journal in Accord BurnTest to detect issues earlier before they are seen in Cassandra
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 03/May/24 21:35
Resolved: 15/May/24 17:04

Right now Cassandra splits a txn data into 2 places: system table, and journal (commit log like structure), when we read we read from both places and zip together.  One issue we face is the logic to join them together is in Accord and kept failing as we would hit unexpected states.

We should simulate the journal logic in BurnTest and call this reconstruct logic so we improve test coverage before Cassandra sees it
Bug: [Analytics] Improve test coverage for downed instances
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 11/May/24 13:50
Resolved: 12/May/24 18:36

This improvement adds test coverage for Cassandra Analytics. We test different scenarios during bulk writes. For example, bulk writes when downed Cassandra instances are encountered. We use different consistency levels, and we ensure the expected success or failure is achieved depending on the configured consistency level. Similarly, we test for when Sidecar instances are down under different consistency levels.
Bug: [Analytics] NullPointerException when reading static column with null values
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 08/May/24 23:53
Resolved: 10/May/24 20:17

The analytics library fails to read static columns that has null values depending on the type. For example, this problem is exhibited in the Timestamp type, where the deserialized object is null, and the type will attempt to get the time from the field. When that occurs it triggers the NullPointerException.
Bug: SIGSEGV on Cassandra v4.1.4
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 17/Apr/24 07:52
Resolved: 06/May/24 13:44

Hello,

Since upgrading to v4.1. we cannat run CAssandra any more. Each start immediately crashes:
{{Apr 17 08:58:34 SVALD108 cassandra[1116450]: # A fatal error has been detected by the Java Runtime Environment:
Apr 17 08:58:34 SVALD108 cassandra[1116450]: #  SIGSEGV (0xb) at pc=0x00007fccaab4d152, pid=1116450, tid=1116451}}

I have added the log from the coe dump.

This issue is perhaps related to https://davecturner.github.io/2021/08/30/seven-year-old-segfault.html ?
Bug: Raise priority of TCM internode messages during critical operations
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 03/Apr/24 16:14
Resolved: 06/May/24 07:13

In a busy cluster, TCM messages may not get propagated throughout the cluster, since they will be ordered together with other P1 messages (for {{TCM_}} prefixed verbs), and with P2 with all Paxos operations.

To avoid this, and make sure we can continue cluster metadata changes, all {{TCM_}}-prefixed verbs should have {{P0}} priority, just like Gossip messages used to. All Paxos messages that involve distributed metadata keyspace should now get an {{URGENT}} flag, which will instruct internode messaging to schedule them on the {{URGENT_MESSAGES}} connection.
Bug: Running with default configuration OOMs under light load
Status: Resolved
Priority: Normal
Resolution: Cannot Reproduce
Created: 05/Apr/24 21:07
Resolved: 05/May/24 21:31

Under very moderate load, Cassandra crashes with direct memory errors.  
{noformat}
ERROR [epollEventLoopGroup-5-16] 2024-04-04 19:16:50,096 JVMStabilityInspector.java:186 - Force heap space OutOfMemoryError in the presence of
java.lang.OutOfMemoryError: Cannot reserve 65536 bytes of direct buffer memory (allocated: 8589921806, limit: 8589934592)
	at java.base/java.nio.Bits.reserveMemory(Bits.java:178)
	at java.base/java.nio.DirectByteBuffer.<init>(DirectByteBuffer.java:121)
	at java.base/java.nio.ByteBuffer.allocateDirect(ByteBuffer.java:332)
	at org.apache.cassandra.utils.memory.BufferPool.allocate(BufferPool.java:238)
	at org.apache.cassandra.utils.memory.BufferPool$LocalPool.get(BufferPool.java:923)
	at org.apache.cassandra.utils.memory.BufferPool$LocalPool.getAtLeast(BufferPool.java:901)
	at org.apache.cassandra.utils.memory.BufferPool.getAtLeast(BufferPool.java:219)
	at org.apache.cassandra.net.BufferPoolAllocator.getAtLeast(BufferPoolAllocator.java:75)
	at org.apache.cassandra.net.BufferPoolAllocator.newDirectBuffer(BufferPoolAllocator.java:63)
	at io.netty.buffer.AbstractByteBufAllocator.directBuffer(AbstractByteBufAllocator.java:188)
	at io.netty.buffer.AbstractByteBufAllocator.directBuffer(AbstractByteBufAllocator.java:179)
	at io.netty.channel.unix.PreferredDirectByteBufAllocator.ioBuffer(PreferredDirectByteBufAllocator.java:53)
	at io.netty.channel.DefaultMaxMessagesRecvByteBufAllocator$MaxMessageHandle.allocate(DefaultMaxMessagesRecvByteBufAllocator.java:120)
	at io.netty.channel.epoll.EpollRecvByteAllocatorHandle.allocate(EpollRecvByteAllocatorHandle.java:75)
	at io.netty.channel.epoll.AbstractEpollStreamChannel$EpollStreamUnsafe.epollInReady(AbstractEpollStreamChannel.java:785)
	at io.netty.channel.epoll.AbstractEpollChannel$AbstractEpollUnsafe$1.run(AbstractEpollChannel.java:425)
	at io.netty.util.concurrent.AbstractEventExecutor.runTask(AbstractEventExecutor.java:174)
	at io.netty.util.concurrent.AbstractEventExecutor.safeExecute(AbstractEventExecutor.java:167)
	at io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:470)
	at io.netty.channel.epoll.EpollEventLoop.run(EpollEventLoop.java:413)
	at io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:997)
	at io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
	at io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
	at java.base/java.lang.Thread.run(Thread.java:840){noformat}
Bug: Add ClusterMetadata.metadataIdentifier to GossipDigestSyn messages
Status: Resolved
Priority: Normal
Resolution: Fixed
Created: 02/May/24 14:37
Resolved: 03/May/24 08:25

We should add \{{ClusterMetadata.instance().metadataIdentifier}} to \{{GossipDigestSyn}} messages and compare with the local one, rejecting anything that has the wrong identifier like we do with cluster name.