apache/cassandra · error · InvalidRequestException

Column %s was not found in table '%s'

Error message

Column %s was not found in table '%s'

What it means

This InvalidRequestException is thrown by `ALTER TABLE ... DROP <column>` when the named column does not exist in the table and `IF EXISTS` was not specified for the column. Cassandra validates the schema change before applying it and refuses to drop a non-existent column unless the caller explicitly tolerated a missing column.

Source

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

        {
            Guardrails.alterTableEnabled.ensureEnabled("ALTER TABLE changing columns", state);
            TableMetadata.Builder builder = table.unbuild();
            removedColumns.forEach(c -> dropColumn(keyspace, table, c, ifColumnExists, builder));
            return keyspace.withSwapped(keyspace.tables.withSwapped(builder.build()));
        }

        @Override
        public boolean compatibleWith(ClusterMetadata metadata)
        {
            return metadata.directory.commonSerializationVersion.isAtLeast(Version.V0);
        }

        private void dropColumn(KeyspaceMetadata keyspace, TableMetadata table, ColumnIdentifier column, boolean ifExists, TableMetadata.Builder builder)
        {
            ColumnMetadata currentColumn = table.getColumn(column);
            if (null == currentColumn) {
                if (!ifExists)
                    throw ire("Column %s was not found in table '%s'", column, table);
                return;
            }

            if (currentColumn.isPrimaryKeyColumn())
                throw ire("Cannot drop PRIMARY KEY column %s", column);

            /*
             * Cannot allow dropping top-level columns of user defined types that aren't frozen because we cannot convert
             * the type into an equivalent tuple: we only support frozen tuples currently. And as such we cannot persist
             * the correct type in system_schema.dropped_columns.
             */
            if (currentColumn.type.isUDT() && currentColumn.type.isMultiCell())
                throw ire("Cannot drop non-frozen column %s of user type %s", column, currentColumn.type.asCQL3Type());

            if (!table.indexes.isEmpty())
                AlterTableStatement.validateIndexesForColumnModification(table, column, false);

            if (!isEmpty(keyspace.views.forTable(table.id)))

View on GitHub (pinned to 88fd0f6a0e)

Solutions

  1. Verify the column exists with `DESCRIBE TABLE ks.tbl` or a query against system_schema.columns, correcting any typo or case-sensitivity issue.
  2. If the drop is intentionally conditional, use `ALTER TABLE ks.tbl DROP IF EXISTS colname` so a missing column is not an error.
  3. If the column was already dropped, remove the redundant statement from the migration script.
  4. Check you are connected to the intended keyspace/table; qualify the table as ks.tbl to rule out keyspace confusion.

Example fix

// before
ALTER TABLE users DROP emial; -- InvalidRequest: column not found
// after
ALTER TABLE users DROP IF EXISTS email;
Defensive patterns

Strategy: validation

Validate before calling

// Verify the column exists before dropping
ResultSet rs = session.execute(
  "SELECT column_name FROM system_schema.columns WHERE keyspace_name=? AND table_name=? AND column_name=?",
  ks, table, column);
boolean exists = rs.iterator().hasNext();
// only run ALTER TABLE ... DROP if exists, or use DROP IF EXISTS

Try / catch

try {
    session.execute("ALTER TABLE ks.tbl DROP " + column);
} catch (com.datastax.oss.driver.api.core.servererrors.InvalidQueryException e) {
    if (e.getMessage().contains("was not found in table")) {
        log.warn("Column already absent; treating drop as no-op");
    } else throw e;
}

Prevention

When it happens

Trigger: Running `ALTER TABLE ks.tbl DROP colname` where colname is misspelled, was already dropped in an earlier migration, or never existed. Also happens in multi-environment deployments where schemas have diverged and a migration script assumes a column is present. The error is skipped only when `DROP IF EXISTS` is used.

Common situations: Idempotent migration frameworks re-running a DROP after a partial failure; typo'd column names (case sensitivity: unquoted identifiers are lowercased, so `DROP Email` looks for `email`); environments where a previous migration step was applied out of order.

Understand the failure class

Background: "Not found" and "does not exist" errors: why "Task not found", "No such folder", and "Can't find" fire when a lookup comes back empty — this error's family across 14 libraries.

Related errors

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