apache/cassandra · info

[# ] Not failing repair due to remote host not supporting…

Error message

[#{}] Not failing repair due to remote host {} not supporting repair message timeouts (version is unknown)

What it means

Logged by RepairMessage.errorHandlingSupported when a repair message verb is known to support timeouts but the remote host's release version cannot be determined from gossip. Instead of failing the repair on timeout, the node conservatively returns ErrorHandling.NONE so the repair is not aborted due to a possibly unsupported feature.

Solutions

1. Wait for gossip to converge (nodetool gossipinfo) so the peer's release version is known, then re-run repair
2. Ensure all nodes are on versions supporting repair message timeouts/retries
3. Investigate why the peer's release version is missing from gossip (stale node, gossip issues)
4. Safe to ignore: the log explicitly says the repair is not failed; verify repairs complete

// check the peer version is known before repair
CassandraVersion v = Gossiper.instance.getReleaseVersion(peer);
boolean versionKnown = v != null;
boolean supportsTimeouts = versionKnown && v.compareTo(RepairMessage.SUPPORTS_RETRY) >= 0;

boolean versionKnown(CassandraVersion v) { return v != null; }

When it happens

Trigger: Receiving a repair message from a node whose gossiped release version is null (peer just joined/restarted, gossip not yet populated) while the verb is in VERB_TIMEOUT_VERSIONS.

Common situations: Rolling upgrades or freshly bootstrapped nodes where gossip release versions have not propagated; decommissioned or flapping nodes with stale/missing gossip state.

Understand the failure class

• Timeouts: ETIMEDOUT, deadlines, and hung requests — what actually expires when a request times out.

Related errors

• Bad NodeState
• Can't upgrade the first node when STATUS =
• Cannot DROP COMPACT STORAGE as some nodes in the cluster
• Extracting tokens from
• Invalid endpoint state for

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

Appendix: source

Thrown at src/java/org/apache/cassandra/repair/messages/RepairMessage.java:285

            {
                return true;
            }
        };
        sendMessageWithRetries(ctx, allowRetry, request, verb, endpoint, callback);
    }

    private static ErrorHandling errorHandlingSupported(SharedContext ctx, InetAddressAndPort from, Verb verb, TimeUUID parentSessionId)
    {
        if (SUPPORTS_RETRY_WITHOUT_VERSION_CHECK.contains(verb))
            return ErrorHandling.RETRY;
        // Repair in mixed mode isn't fully supported, but also not activally blocked... so in the common case all participants
        // will be on the same version as this instance, so can avoid the lookup from gossip
        CassandraVersion remoteVersion = ctx.gossiper().getReleaseVersion(from);
        if (remoteVersion == null)
        {
            if (VERB_TIMEOUT_VERSIONS.containsKey(verb))
            {
                logger.warn("[#{}] Not failing repair due to remote host {} not supporting repair message timeouts (version is unknown)", parentSessionId, from);
                return ErrorHandling.NONE;
            }
            return ErrorHandling.TIMEOUT;
        }
        if (remoteVersion.compareTo(SUPPORTS_RETRY) >= 0)
            return ErrorHandling.RETRY;
        CassandraVersion timeoutVersion = VERB_TIMEOUT_VERSIONS.get(verb);
        if (timeoutVersion == null || remoteVersion.compareTo(timeoutVersion) >= 0)
            return ErrorHandling.TIMEOUT;
        return ErrorHandling.NONE;
    }

    public static void sendFailureResponse(SharedContext ctx, Message<?> respondTo)
    {
        Message<?> reply = respondTo.failureResponse(RequestFailureReason.UNKNOWN);
        ctx.messaging().send(reply, respondTo.from());
    }

View on GitHub (pinned to 88fd0f6a0e)