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

  1. Let the lagging node sync cluster metadata (stay joined to the cluster, verify gossip, restart if needed) until token maps converge, then retry migration
  2. Inspect the dumpDiff output to identify which tokens/ranges differ and whether a bootstrap/decommission was interrupted
  3. 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

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


AI-assisted analysis of apache/cassandra@88fd0f6a0e (2026-09-10). Data as JSON: /api/errors/3ea7c171d01c862e. Report an issue: GitHub.