apache/cassandra · error · IllegalStateException

Ignored host(s) %s don't exist in the cluster

Error message

Ignored host(s) %s don't exist in the cluster

What it means

upgradeFromGossip accepts an 'ignored' set of hosts to exclude from the gossip-to-TCM upgrade. Before proceeding, it validates that every ignored host exists in the cluster's directory of addresses; if any are unknown, it throws IllegalStateException naming the missing hosts, because ignoring non-existent nodes would silently corrupt the upgrade process.

Source

Thrown at src/java/org/apache/cassandra/tcm/ClusterMetadataService.java:449

            throw new IllegalStateException(msg);
        }

        ClusterMetadata metadata = metadata();
        if (metadata.myNodeState() != NodeState.JOINED)
        {
            String msg = String.format("Initial CMS node needs to be fully joined, not: %s", metadata.myNodeState());
            logger.error(msg);
            throw new IllegalStateException(msg);
        }

        Set<InetAddressAndPort> existingMembers = metadata.fullCMSMembers();

        if (!metadata.directory.allAddresses().containsAll(ignored))
        {
            Set<InetAddressAndPort> allAddresses = Sets.newHashSet(metadata.directory.allAddresses());
            String msg = String.format("Ignored host(s) %s don't exist in the cluster", Sets.difference(ignored, allAddresses));
            logger.error(msg);
            throw new IllegalStateException(msg);
        }

        for (Map.Entry<NodeId, NodeVersion> entry : metadata.directory.versions.entrySet())
        {
            NodeVersion version = entry.getValue();
            InetAddressAndPort ep = metadata.directory.getNodeAddresses(entry.getKey()).broadcastAddress;
            if (ignored.contains(ep))
            {
                // todo; what do we do if an endpoint has a mismatching gossip-clustermetadata?
                //       - we could add the node to --ignore and force this CM to it?
                //       - require operator to bounce/manually fix the CM on that node
                //       for now just requiring that any ignored host is also down
//                if (FailureDetector.instance.isAlive(ep))
//                    throw new IllegalStateException("Can't ignore " + ep + " during CMS migration - it is not down");
                logger.info("Endpoint {} running {} is ignored", ep, version);
                continue;
            }

View on GitHub (pinned to 88fd0f6a0e)

Solutions

  1. Remove the unknown host(s) from the ignored set and re-run upgradeFromGossip.
  2. Verify host addresses against the live directory (metadata.directory.allAddresses() or nodetool status) before passing them.
  3. Fix IP typos or use exact registered addresses (IP:port) as they appear in the node directory.
  4. If the node was decommissioned, it no longer needs to be in the ignored list — just drop it.

Example fix

// before
Set<InetAddressAndPort> ignored = Sets.newHashSet(toAddr("10.0.0.99")); // not in cluster
service.upgradeFromGossip(ignored);
// after
Set<InetAddressAndPort> all = ClusterMetadata.current().directory.allAddresses();
ignored.retainAll(all);
service.upgradeFromGossip(ignored);
Defensive patterns

Strategy: validation

Validate before calling

Set<InetAddressAndPort> all = ClusterMetadata.current().directory.allAddresses();
Set<InetAddressAndPort> unknown = Sets.difference(ignored, all);
if (!unknown.isEmpty()) throw new IllegalArgumentException("Unknown ignored hosts: " + unknown);

Try / catch

try { service.upgradeFromGossip(ignored); } catch (IllegalStateException e) { logger.error("Invalid ignored set: {}", e.getMessage()); }

Prevention

When it happens

Trigger: Calling upgradeFromGossip(Set<InetAddressAndPort> ignored) where at least one address in 'ignored' is not present in metadata.directory.allAddresses() — typically a typo'd IP, a decommissioned node, or a host from a different cluster.

Common situations: Copy-pasting host lists from another cluster or an old operations doc, specifying nodes that were already removed via decommission, DNS-resolved names mismatching stored IPs, or misconfigured upgrade automation scripts.

Understand the failure class

Background: "Must be a positive integer", "Invalid value", "Unsupported": the invalid-argument-value error family, when a library rejects the value you pass — this error's family across 35 libraries.

Related errors

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