apache/cassandra · error · InvalidRequestException

Unknown keyspace: '" + keyspaceName + "'

Error message

Unknown keyspace: '" + keyspaceName + "'

What it means

AbstractSchemaMetadataTable (backing tables like system_schema_virtual / schema object listings) splits each partition key into (objectType, keyspaceName). If the keyspace named in the key does not exist in Schema, it throws InvalidRequestException, indicating a query against a nonexistent keyspace.

Source

Thrown at src/java/org/apache/cassandra/db/virtual/AbstractSchemaMetadataTable.java:219

                    addFieldRow(result, keyspace, udt, field.toString());
            }
        }
        return result;
    }

    @Override
    public DataSet data(DecoratedKey partitionKey)
    {
        SimpleDataSet result = new SimpleDataSet(metadata());

        ByteBuffer key = partitionKey.getKey();
        ByteBuffer[] components = ((CompositeType) metadata().partitionKeyType).split(key);
        String objectType = UTF8Type.instance.compose(components[0]);
        String keyspaceName = UTF8Type.instance.compose(components[1]);

        KeyspaceMetadata keyspace = Schema.instance.getKeyspaceMetadata(keyspaceName);
        if (keyspace == null)
            throw new InvalidRequestException("Unknown keyspace: '" + keyspaceName + '\'');

        ObjectType type = ObjectType.parse(objectType);
        if (type == null)
            throw new InvalidRequestException("Unknown object type: '" + objectType +
                                              "'. Valid types are: " + Arrays.toString(ObjectType.values()));

        switch (type)
        {
            case KEYSPACE:
                addKeyspaceRow(result, keyspace);
                break;
            case TABLE:
                for (TableMetadata table : keyspace.tables)
                    addTableRow(result, keyspace, table);
                break;
            case COLUMN:
                for (TableMetadata table : keyspace.tables)
                    for (ColumnMetadata column : table.columns())

View on GitHub (pinned to 88fd0f6a0e)

Solutions

1. Verify the keyspace exists: run `DESCRIBE KEYSPACES` or query system_schema.keyspaces before querying the metadata table
2. Fix identifier casing (keyspace names are case-sensitive when quoted)
3. Update application configuration to the current keyspace name
4. If hit after DROP KEYSPACE, re-read fresh schema metadata (clients may cache stale schema).

Example fix

// before
SELECT * FROM system_schema_virtual.tables WHERE keyspace_name = 'old_ks';
// after
SELECT keyspace_name FROM system_schema.keyspaces; // confirm 'old_ks' exists first
// then query only existing keyspaces

Row r = session.execute("SELECT keyspace_name FROM system_schema.keyspaces WHERE keyspace_name = ?", ks).one();
if (r == null) throw new IllegalArgumentException("Unknown keyspace: " + ks);

try { session.execute(schemaQuery); } catch (InvalidRequestException e) { if (e.getMessage().startsWith("Unknown keyspace")) refreshSchemaAndFixConfig(); else throw e; }

When it happens

Trigger: SELECT from a schema-metadata virtual table with a partition key or WHERE clause naming a keyspace that was dropped or never created, e.g. `SELECT * FROM system_schema_virtual.tables WHERE keyspace_name = 'old_ks'`.

Common situations: Stale application config pointing at a dropped keyspace; case-sensitivity issues (quoted vs unquoted identifiers); race between DROP KEYSPACE and concurrent schema-table queries; tools enumerating keyspaces from cached metadata.

Related errors

• Unknown object type: '" + objectType + "'. Valid types are:
• Keyspace %s doesn't exist
• Statement on keyspace %s cannot refer to a user type in keys
• Index %s is not in the same keyspace as the queried table.
• Operator %s not supported for txn_id

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