apache/cassandra · error · java.lang.IllegalStateException

Can't abort a %s operation for a node %s (%s) that is UP - r

Error message

Can't abort a %s operation for a node %s (%s) that is UP - run abortdecommission on that instance

What it means

When aborting a decommission/remove/move for a REMOTE node, abortHelper refuses if Gossiper reports that node as UP. The failure must be confirmed (node down) before CancelInProgressSequence is committed; otherwise the operator is told to run abortdecommission on that live instance itself. This prevents cancelling a sequence on a node that may actually be progressing.

Source

Thrown at src/java/org/apache/cassandra/tcm/sequences/SingleNodeSequences.java:290

                throw new IllegalStateException(msg);
            }
        }
        if (toAbort.equals(metadata.myNodeId()))
        {
            if (ssMode != null && StorageService.instance.operationMode() != ssMode)
            {
                String msg = String.format("Can't abort a %s operation unless it has failed", kind);
                logger.info(msg);
                throw new IllegalStateException(msg);
            }
            StorageService.instance.clearTransientMode();
        }
        else if (Gossiper.instance.isAlive(metadata.directory.endpoint(toAbort)))
        {
            String msg = String.format("Can't abort a %s operation for a node %s (%s) that is UP - run abortdecommission on that instance",
                                       kind, toAbort, metadata.directory.endpoint(toAbort));
            logger.info(msg);
            throw new IllegalStateException(msg);
        }
        ClusterMetadataService.instance().commit(new CancelInProgressSequence(toAbort));
    }
}

View on GitHub (pinned to 88fd0f6a0e)

Solutions

1. Run the abort command on the UP node itself as the message instructs (abortdecommission on that instance)
2. Verify the node is really down (nodetool gossipinfo / ping) before aborting remotely
3. If the node is truly gone, wait for gossip to mark it dead (or force its removal via the appropriate removal path) then retry

Example fix

// before
// on coordinator: nodetool abortremove <nodeId>   // node still UP
// after
// ssh to the target node and run there:
nodetool abortdecommission

// abort remotely only if Gossiper marks the target down
if (Gossiper.instance.isAlive(endpoint))
    throw new IllegalStateException("Target node is UP - run abortdecommission on that instance");

try { abortRemote(nodeId); }
catch (IllegalStateException e) {
    if (e.getMessage().contains("that is UP")) { /* run the abort on the target node itself */ }
    else throw e;
}

When it happens

Trigger: abortRemoveNode/abortDecommission targeting a node that Gossiper still marks alive; network partition healed and the node rejoined before the abort was issued.

Common situations: Operator aborts a remove after the 'failed' node came back online; DNS/IP restored so gossip marks the endpoint UP; abort run from the wrong coordinator.

Understand the failure class

Background: "Invalid state transition" errors: "status must be X, actually Y", "already rejected/charging/uninstalled", "cannot ... while running" — what they mean when a library rejects your call — this error's family across 31 libraries.

Related errors

• Bad NodeState
• Extracting tokens from %s sequence is neither necessary nor
• Can't upgrade the first node when STATUS =
• Unknown host in epState for
• Can't commit transformations when running in gossip mode. En

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