apache/cassandra · warning
Initiator tokenmap different from ours
Error message
Initiator tokenmap different from ours
What it means
Warning logged by the CMS initialization handler when the initiator's token map (ring/token assignment) differs from the local node's ClusterMetadata.tokenMap. As with the directory mismatch, the handler marks the verification as failed and returns metadataMatches=false, so the initiator will not proceed with migration until tokens agree.
Source
Thrown at src/java/org/apache/cassandra/tcm/migration/Election.java:243
if (!updateInitiator(null, message.payload.initiator))
throw new IllegalStateException(String.format("Got duplicate initiate migration message from %s, migration is already started by %s", message.from(), initiator()));
logger.info("Sending initiation response");
Directory initiatorDirectory = message.payload.directory;
TokenMap initiatorTokenMap = message.payload.tokenMap;
UUID initiatorSchemaVersion = message.payload.schemaVersion;
ClusterMetadata metadata = ClusterMetadata.current();
boolean match = true;
if (!initiatorDirectory.equals(metadata.directory))
{
match = false;
logger.warn("Initiator directory different from our");
initiatorDirectory.dumpDiff(metadata.directory);
}
if (!initiatorTokenMap.equals(metadata.tokenMap))
{
match = false;
logger.warn("Initiator tokenmap different from ours");
initiatorTokenMap.dumpDiff(metadata.tokenMap);
}
UUID schemaDigest = SchemaKeyspace.calculateSchemaDigest();
if (!initiatorSchemaVersion.equals(schemaDigest))
{
match = false;
logger.warn("Initiator schema different from our: {} != {}", initiatorSchemaVersion, schemaDigest);
}
messaging.send(message.responseWith(new CMSInitializationResponse(message.payload.initiator, match)), message.from());
}
}
public class AbortHandler implements IVerbHandler<CMSInitializationRequest.Initiator>
{
@Override
public void doVerb(Message<CMSInitializationRequest.Initiator> message) throws IOException
{
logger.info("Received election abort message {} from {}", message.payload, message.from());View on GitHub (pinned to 88fd0f6a0e)
Solutions
- Let the lagging node sync cluster metadata (stay joined to the cluster, verify gossip, restart if needed) until token maps converge, then retry migration
- Inspect the dumpDiff output to identify which tokens/ranges differ and whether a bootstrap/decommission was interrupted
- Confirm all nodes run a compatible Cassandra version with TCM enabled so token map state is represented consistently
Defensive patterns
Strategy: validation
Validate before calling
if (!initiatorTokenMap.equals(ClusterMetadata.current().tokenMap)) {
initiatorTokenMap.dumpDiff(ClusterMetadata.current().tokenMap);
// abort migration until token maps converge
} Prevention
- Never run CMS migration while a bootstrap or decommission is in progress
- Verify token assignments agree cluster-wide (nodetool status / ring) before migration
- Keep all nodes on TCM-enabled versions so token map state is uniform
When it happens
Trigger: During TCM_INIT_MIG_REQ handling, initiatorTokenMap.equals(metadata.tokenMap) is false — e.g. a node still has pre-migration token assignments, missed a token movement, or has stale bootstrap/decommission token data.
Common situations: A node was down while another node bootstrapped or decommissioned (token ranges moved); mixing gossip-era token info with TCM metadata; a partially completed bootstrap left token maps inconsistent across nodes.
Understand the failure class
Background: Schema validation failed / invalid input schema: payload rejected because its shape doesn't match the expected schema — this error's family across 28 libraries.
Related errors
- Initiator directory different from our
- This cluster is migrating to cluster metadata, can't move un
- This cluster is migrating to cluster metadata, can't abort %
- The tokens provided ${tokens} do not match with in progress
- Value for key {} is only present in the left set: {}
AI-assisted analysis of apache/cassandra@88fd0f6a0e (2026-09-10).
Data as JSON: /api/errors/3ea7c171d01c862e.
Report an issue: GitHub.