apache/cassandra · warning
Value for key {} is only present in the left set: {}
Error message
Value for key {} is only present in the left set: {} What it means
This is a diagnostic warning from Directory.dumpDiff, a comparison helper used when two ClusterMetadata directories are expected to be identical but are not. It logs every key (e.g. node id or endpoint mapping) that exists in the left directory but is missing from the right one. It is purely informational logging, not a thrown exception, emitted during CMS metadata verification.
Source
Thrown at src/java/org/apache/cassandra/tcm/membership/Directory.java:950
}
if (!Objects.equals(addresses, other.addresses))
{
logger.warn("Addresses differ: {} != {}", addresses, other.addresses);
dumpDiff(logger, addresses, other.addresses);
}
}
public static <K, V> void dumpDiff(Logger logger, Map<K, V> l, Map<K, V> r)
{
for (K k : Sets.intersection(l.keySet(), r.keySet()))
{
V lv = l.get(k);
V rv = r.get(k);
if (!Objects.equals(lv, rv))
logger.warn("Values for key {} differ: {} != {}", k, lv, rv);
}
for (K k : Sets.difference(l.keySet(), r.keySet()))
logger.warn("Value for key {} is only present in the left set: {}", k, l.get(k));
for (K k : Sets.difference(r.keySet(), l.keySet()))
logger.warn("Value for key {} is only present in the right set: {}", k, r.get(k));
}
public static class RemovedNode implements Comparable<RemovedNode>
{
public final Epoch removedIn;
public final NodeId id;
public final InetAddressAndPort endpoint;
public RemovedNode(Epoch removedIn, NodeId id, InetAddressAndPort endpoint)
{
this.removedIn = removedIn;
this.id = id;
this.endpoint = endpoint;
}
View on GitHub (pinned to 88fd0f6a0e)
Solutions
- Compare cluster metadata across nodes (nodetool CMS operations / ClusterMetadata dumps) and let the CMS replicate so both directories converge
- Identify the missing node entries from the log and re-run the migration/initiation once all peer nodes are up and gossip-consistent
- If drift is permanent (e.g. from a bad snapshot restore), follow the CMS recovery/re-bootstrap procedure for the diverging node
Example fix
// before: comparing against stale directory
if (!initiatorDirectory.equals(metadata.directory)) { initiatorDirectory.dumpDiff(metadata.directory); }
// after: ensure metadata is current before comparing
ClusterMetadata metadata = ClusterMetadata.current();
if (!initiatorDirectory.equals(metadata.directory)) { initiatorDirectory.dumpDiff(metadata.directory); /* investigate log output, resync via CMS */ } Defensive patterns
Strategy: validation
Validate before calling
if (!expectedDirectory.equals(ClusterMetadata.current().directory)) {
logger.warn("Directory mismatch detected before operation");
expectedDirectory.dumpDiff(ClusterMetadata.current().directory);
// abort or resync before proceeding
} Prevention
- Verify cluster metadata equality across nodes before initiating migrations
- Keep all nodes joined and gossip-consistent; avoid running operations while a node is catching up
- Monitor logs for dumpDiff warnings as early signals of metadata drift
When it happens
Trigger: Directory.dumpDiff(this, other) is invoked after an equals() comparison fails between two Directory instances, e.g. when a CMS initialization/migration peer reports a directory that differs from the local one, and some node entries exist only in the initiator's directory.
Common situations: Node joins or removals committed on the initiator but not yet replicated to the comparing node; a node bootstrapped against a stale or diverging CMS state; split-brain or restored-from-snapshot metadata drift during cluster migration to TCM.
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
- Value for key {} is only present in the right set: {}
- Initiator directory different from our
- In progress sequences differ: {} != {}
- Extensions differ: {} != {}
- CMS Membership differ: {} != {}
AI-assisted analysis of apache/cassandra@88fd0f6a0e (2026-09-10).
Data as JSON: /api/errors/428d19a1003dbf2e.
Report an issue: GitHub.