apache/cassandra · error · InvalidRequestException

Table '%s.%s' is already being dropped

Error message

Table '%s.%s' is already being dropped

What it means

DROP TABLE was executed on a table that uses Accord-based transactional features and is already marked with a pending drop. Cassandra rejects the redundant drop to avoid a second, conflicting schema mutation on a table already being removed. It means the drop has already been committed or requested and is awaiting completion.

Source

Thrown at src/java/org/apache/cassandra/cql3/statements/schema/DropTableStatement.java:106

        KeyspaceMetadata keyspace = schema.getNullable(keyspaceName);

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

        if (null == table)
        {
            if (ifExists)
                return schema;

            throw ire("Table '%s.%s' doesn't exist", keyspaceName, tableName);
        }

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

        if (table.requiresAccordSupport() && table.params.pendingDrop)
            throw ire("Table '%s.%s' is already being dropped", keyspaceName, tableName);

        Iterable<ViewMetadata> views = keyspace.views.forTable(table.id);
        if (!isEmpty(views))
        {
            throw ire("Cannot drop a table when materialized views still depend on it (%s)",
                      keyspaceName,
                      join(", ", transform(views, ViewMetadata::name)));
        }

        return schema.withAddedOrUpdated(keyspace.withSwapped(keyspace.tables.without(table)));
    }

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

    public void authorize(ClientState client)

View on GitHub (pinned to 88fd0f6a0e)

Solutions

1. Wait for the in-flight drop to complete (check schema agreement / system_schema) before reissuing the command
2. Use DROP TABLE IF EXISTS so an already-dropped (or dropping) table is not an error
3. Inspect table.params.pendingDrop via schema tables to confirm the drop is already pending
4. If the drop is stuck, resolve the pending schema change (check node schema versions) instead of issuing another drop

Example fix

// before
DROP TABLE ks.tbl;
// after (idempotent)
DROP TABLE IF EXISTS ks.tbl;

var rows = session.execute("SELECT params FROM system_schema.tables WHERE keyspace_name=? AND table_name=?", ks, table);
if (rows.isEmpty()) return; // already gone
// if pendingDrop is exposed/true, skip issuing DROP again

try { session.execute("DROP TABLE IF EXISTS " + ks + "." + table); }
catch (InvalidRequest e) { if (e.getMessage().contains("already being dropped")) log.info("Drop already in progress"); else throw e; }

When it happens

Trigger: Executing DROP TABLE (without IF EXISTS) twice against an Accord-enabled table whose TableParams.pendingDrop is still true because the first drop's schema change has not fully propagated/finished.

Common situations: Retrying a DROP TABLE after a timeout or schema-agreement delay; concurrent clients issuing the same drop; scripts that drop a transactional table and don't wait for the schema change to converge across nodes.

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

• category %s not found in %s
• 'Get CIDR groups for IP' operation not supported by %s
• ACCESS TO DATACENTERS operations not supported by AllowAllNe
• frozen<> is only allowed on collections, tuples, and user-de
• System keyspace '%s' is not user-modifiable

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