What causes "Error while executing truncate" in apache/cassandra?

Retry the truncate once the cluster is healthy

apache/cassandra · error · RuntimeException

Error while executing truncate

Error message

Error while executing truncate

What it means

NodeProbe.truncate delegates to StorageServiceMBean.truncate over JMX and wraps TimeoutException/IOException in a RuntimeException, meaning the truncate RPC to the node timed out or failed at the transport level — not that the data wasn't (eventually) truncated.

Solutions

Retry the truncate once the cluster is healthy
Check all target nodes are UP (nodetool status) and logs for truncate errors
Increase timeout via the truncate_rpc_timeout setting if large truncates regularly time out
Verify schema agreement and no pending repairs/migrations conflicting with the truncate

Example fix

// before
nodetool truncate keyspace1 events   # node down
// after
nodetool status                       # ensure all UP
nodetool truncate keyspace1 events

Defensive patterns

Strategy: retry

Validate before calling

// Ensure all nodes are UP before truncating
// nodetool status | grep -v '^UN' -> abort if any non-UN node

Try / catch

try {
    probe.truncate(keyspaceName, tableName);
} catch (RuntimeException e) {
    if (e.getMessage().equals("Error while executing truncate") && attempts < 3) {
        Thread.sleep(backoffMs);
        retry();
    } else throw e;
}

Prevention

Check nodetool status shows all nodes UP before truncating
Increase truncate_rpc_timeout for very large tables
Avoid truncating during heavy load, repairs, or streaming
Check node logs for the underlying truncate failure

When it happens

Trigger: nodetool truncate keyspace table when the server-side truncate exceeds the timeout or the connection breaks: very large table with slow snapshot/truncate across replicas, an overloaded or down node, or truncate_uncooperative / consistency issues.

Common situations: Truncating a huge table on a cluster with slow replicas; a node down or in bad state during truncate; gc_grace/lock contention causing truncate timeouts; JMX/network instability.

Understand the failure class

Background: Request timed out: what client-side request timeouts mean across libraries (Request timed out, TIMED_OUT, APITimeoutError) — this error's family across 39 libraries.

Related errors

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

Appendix: source

Thrown at src/java/org/apache/cassandra/tools/NodeProbe.java:1267

    public String getOperationMode()
    {
        return ssProxy.getOperationMode();
    }

    public boolean isStarting()
    {
        return ssProxy.isStarting();
    }

    public void truncate(String keyspaceName, String tableName)
    {
        try
        {
            ssProxy.truncate(keyspaceName, tableName);
        }
        catch (TimeoutException e)
        {
            throw new RuntimeException("Error while executing truncate", e);
        }
        catch (IOException e)
        {
            throw new RuntimeException("Error while executing truncate", e);
        }
    }

    public EndpointSnitchInfoMBean getEndpointSnitchInfoProxy()
    {
        try
        {
            return JMX.newMBeanProxy(mbeanServerConn, new ObjectName("org.apache.cassandra.db:type=EndpointSnitchInfo"), EndpointSnitchInfoMBean.class);
        }
        catch (MalformedObjectNameException e)
        {
            throw new RuntimeException(e);
        }
    }

View on GitHub (pinned to 88fd0f6a0e)