apache/cassandra · error · InvalidRequestException

Cannot use ALTER TABLE on a table that is being dropped.

Error message

Cannot use ALTER TABLE on a table that is being dropped.

What it means

Thrown when ALTER TABLE is issued on a table whose TableMetadata.params.pendingDrop is true, i.e. the table is scheduled to be dropped (in-flight DROP in the Accord/transactional schema epoch pipeline). Cassandra refuses further DDL on a table already being torn down.

Solutions

Check whether the DROP was intended; if so, drop the ALTER from the migration
Re-issue the ALTER after the drop completes (it will then fail with 'doesn't exist', confirming ordering)
Serialize DDL: ensure only one coordinator/tool issues schema changes for the table at a time

Example fix

// before
// ALTER and DROP queued concurrently
session.execute("DROP TABLE my_app.events");
session.execute("ALTER TABLE my_app.events ADD extra text"); // race
// after
// pick one: either keep the table and ALTER it, or drop it — not both
session.execute("ALTER TABLE my_app.events ADD extra text");

Defensive patterns

Strategy: validation

Validate before calling

// ensure no concurrent DROP is queued for the same table before ALTER
boolean pendingDrop = /* from TableMetadata */ table.params.pendingDrop;
if (pendingDrop) throw new IllegalStateException("Table is being dropped; skipping ALTER");

Try / catch

try {
    session.execute(alter);
} catch (InvalidRequestException e) {
    if (e.getMessage().contains("being dropped"))
        log.warn("ALTER raced with DROP on {}; aborting migration step", tableName);
    else throw e;
}

Prevention

Serialize all DDL through a single coordinator/lock
Do not batch ALTER and DROP for the same table in concurrent jobs
Order migrations strictly; avoid retrying an ALTER after a DROP of the same table

When it happens

Trigger: ALTER TABLE statement applied while table.params.pendingDrop is true — typically when an ALTER races with a DROP TABLE of the same table, or a stale/queued schema statement lands after a drop was initiated

Common situations: Concurrent migration tooling issuing ALTER and DROP in parallel; a long-running ALTER statement submitted just before a DROP and retried after the drop begins; replayed DDL from a batch that also drops the table.

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

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

Appendix: source

Thrown at src/java/org/apache/cassandra/cql3/statements/schema/AlterTableStatement.java:135

    public Keyspaces apply(ClusterMetadata metadata)
    {
        Keyspaces schema = metadata.schema.getKeyspaces();
        KeyspaceMetadata keyspace = schema.getNullable(keyspaceName);

        TableMetadata table = null == keyspace
                            ? null
                            : keyspace.getTableOrViewNullable(tableName);

        if (null == table)
        {
            if (!ifExists)
                throw ire("Table '%s.%s' doesn't exist", keyspaceName, tableName);
            return schema;
        }

        if (table.params.pendingDrop)
            throw ire("Cannot use ALTER TABLE on a table that is being dropped.");

        if (table.isView())
            throw ire("Cannot use ALTER TABLE on a materialized view; use ALTER MATERIALIZED VIEW instead");

        return schema.withAddedOrUpdated(apply(metadata.nextEpoch(), keyspace, table, metadata));
    }

    SchemaChange schemaChangeEvent(KeyspacesDiff diff)
    {
        return new SchemaChange(Change.UPDATED, Target.TABLE, keyspaceName, tableName);
    }

    public void authorize(ClientState client)
    {
        client.ensureTablePermission(keyspaceName, tableName, Permission.ALTER);
    }

    @Override

View on GitHub (pinned to 88fd0f6a0e)