Node[ ] discovered but doesn't have service[ ]. Ignored.

Error message

Node[%s] discovered but doesn't have service[%s]. Ignored.

What it means

Log warning in DruidNodeDiscoveryProvider.NodeDiscoveryListener indicating a discovered node announcement does not contain the specific service this listener subscribed to, so the node is ignored for that listener. It is informational: the node exists but is not a match for the requested service type.

Solutions

Verify the announced service keys on the node (check its ZK announcement or DiscoveryDruidNode logs) match the expected DruidNodeDiscoveryProvider.ServiceType.
Upgrade/align cluster versions so service key naming is consistent.
Point the consumer at the correct service type for the node role (e.g. data-server vs query service).
Confirm extensions providing the service are loaded on the announcing node.

Defensive patterns

Strategy: validation

Validate before calling

// Confirm the node announces the service you listen for
if (!node.getServices().containsKey(DruidNodeDiscoveryProvider.ServiceType.DATASERVER.getBaseName())) {
  log.warn("Node %s does not announce data-server; upgrade it", node);
}

Prevention

Align service key expectations with the cluster's Druid version (e.g. data-server vs split services)
Listen on the service type matching the node role
Upgrade old nodes still announcing legacy service keys

When it happens

Trigger: A node announces itself but its services map lacks the service key the listener filtered on (checked via node.getServices().containsKey(service)); e.g. a broker announced while listening for 'data-server' service, or version skew changed service keys.

Common situations: Mixed Druid versions where service keys were renamed or consolidated (e.g. historical now announces 'data-server' instead of separate query/data services); watchers configured for a role/service combination the nodes don't provide.

Understand the failure class

Background: "is required", "must be set", "missing required field": configuration validation errors across open-source libraries — this error's family across 36 libraries.

Related errors

AI-assisted analysis of apache/druid@9b90983fd2 (2026-09-07). Data as JSON: /api/errors/414f35487b87c999. Report an issue: GitHub.

Appendix: source

Thrown at server/src/main/java/org/apache/druid/discovery/DruidNodeDiscoveryProvider.java:185

     */
    class FilteringUpstreamListener implements DruidNodeDiscovery.Listener
    {
      @Override
      public void nodesAdded(Collection<DiscoveryDruidNode> nodesDiscovered)
      {
        synchronized (lock) {
          List<DiscoveryDruidNode> nodesAdded = new ArrayList<>();
          for (DiscoveryDruidNode node : nodesDiscovered) {
            if (node.getServices().containsKey(service)) {
              DiscoveryDruidNode prev = nodes.putIfAbsent(node.getDruidNode().getHostAndPortToUse(), node);

              if (prev == null) {
                nodesAdded.add(node);
              } else {
                log.warn("Node[%s] discovered but already exists [%s].", node, prev);
              }
            } else {
              log.warn("Node[%s] discovered but doesn't have service[%s]. Ignored.", node, service);
            }
          }

          if (nodesAdded.isEmpty()) {
            // Don't bother listeners with an empty update, it doesn't make sense.
            return;
          }

          Collection<DiscoveryDruidNode> unmodifiableNodesAdded = Collections.unmodifiableCollection(nodesAdded);
          for (Listener listener : listeners) {
            try {
              listener.nodesAdded(unmodifiableNodesAdded);
            }
            catch (Exception ex) {
              log.error(ex, "Listener[%s].nodesAdded(%s) threw exception. Ignored.", listener, nodesAdded);
            }
          }
        }

View on GitHub (pinned to 9b90983fd2)