What causes "Error while decommissioning node: " in apache/cassandra?

Inspect the cause message in the log line above the exception to find the root failure

apache/cassandra · critical · java.lang.RuntimeException

Error while decommissioning node:

Error message

Error while decommissioning node:

What it means

UnbootstrapAndLeave.executeNext wraps the commit of mid-leave transformations; when an ExecutionException surfaces it marks decommission failed and rethrows a RuntimeException prefixed 'Error while decommissioning node:'. The underlying cause (e.getCause().getMessage()) indicates why the schema/range movement commit failed during unbootstrap. JVMStabilityInspector also inspects the throwable, so some causes may additionally affect node stability.

Source

Thrown at src/java/org/apache/cassandra/tcm/sequences/UnbootstrapAndLeave.java:206

                    return continuable();
                }
                break;
            case MID_LEAVE:
                try
                {
                    streams.execute(startLeave.nodeId(),
                                    startLeave.delta(),
                                    midLeave.delta(),
                                    finishLeave.delta());
                    ClusterMetadataService.instance().commit(midLeave);
                }
                catch (ExecutionException e)
                {
                    if (startLeave.nodeId().equals(ClusterMetadata.current().myNodeId()))
                        StorageService.instance.markDecommissionFailed();
                    JVMStabilityInspector.inspectThrowable(e);
                    logger.error("Error while decommissioning node: {}", e.getCause().getMessage());
                    throw new RuntimeException("Error while decommissioning node: " + e.getCause().getMessage());
                }
                catch (Throwable t)
                {
                    logger.warn("Exception committing midLeave, will retry", t);
                    JVMStabilityInspector.inspectThrowable(t);
                    return continuable();
                }
                break;
            case FINISH_LEAVE:
                try
                {
                    ClusterMetadataService.instance().commit(finishLeave);
                    StorageService.instance.clearTransientMode();
                }
                catch (Throwable t)
                {
                    logger.warn("Exception committing finishLeave, will retry", t);
                    JVMStabilityInspector.inspectThrowable(t);

View on GitHub (pinned to 88fd0f6a0e)

Solutions

Inspect the cause message in the log line above the exception to find the root failure
Fix the underlying issue (restore CMS connectivity, resolve conflicting topology operation), then run abortdecommission or retry decommission
If the node is stuck in a failed decommission state, use nodetool abortdecommission to cancel the sequence

Defensive patterns

Strategy: try-catch

Validate before calling

// ensure CMS reachability and no conflicting topology change before decommissioning
assert ClusterMetadataService.instance().current().isAccessible();

Try / catch

try { executeDecommission(); }
catch (RuntimeException e) {
    if (e.getMessage().startsWith("Error while decommissioning node:")) {
        logger.error("decommission failed: {}", e.getMessage());
        // inspect cause, fix connectivity/conflict, then abort or retry
    }
}

Prevention

Avoid running concurrent topology changes during decommission
Monitor CMS connectivity/quorum throughout unbootstrap
On failure, resolve root cause from the logged cause message, then abortdecommission or retry

When it happens

Trigger: ExecutionException from committing a midLeave/midUnbootstrap transformation during decommission - e.g. cluster metadata commit rejected, another concurrent topology change, or a failure in the async execution of range movement.

Common situations: Decommission interrupted by concurrent topology operations; node losing quorum with CMS mid-unbootstrap; timeouts during streaming/metadata transitions.

Related errors

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