apache/cassandra · info
Table . (id: ) no longer exists. It may have been dropped.
Error message
Table {}.{} (id: {}) no longer exists. It may have been dropped. What it means
In AccordDebugKeyspace, when rendering a virtual-table row for a TableMigrationState, the table's id can no longer be resolved from Schema. The code logs a warning 'Table {ks}.{table} (id: {}) no longer exists. It may have been dropped.' and skips the row instead of failing. It reflects a race between schema drops and migration-state bookkeeping.
Solutions
- Verify the table actually exists: run DESC TABLE or query system_schema.tables for the keyspace/table named in the warning.
- Re-run the virtual table query after the migration state is cleaned up; the stale entry is skipped harmlessly.
- If the table should exist, restore it from schema or recreate it; ensure the drop was intentional.
Defensive patterns
Strategy: validation
Validate before calling
// verify table existence before relying on Accord debug output
String ks = state.keyspaceName, tbl = state.tableName;
boolean exists = session.execute("SELECT keyspace_name FROM system_schema.tables WHERE keyspace_name=? AND table_name=?", ks, tbl).iterator().hasNext(); Prevention
- Avoid concurrent DROP TABLE while inspecting Accord migration virtual tables.
- Re-query after schema changes settle.
- Confirm table existence in system_schema when a row is missing.
When it happens
Trigger: SELECT from the Accord debug virtual tables while a table that was being migrated to Accord (or tracked in tableStates) is dropped concurrently; listing migration states after a DROP TABLE removed the schema entry.
Common situations: Debugging Accord migrations on a schema where tables were dropped; racing DROP TABLE with virtual-table queries; stale TableMigrationState entries after schema churn.
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
- Accord transaction uses dropped tables
- Can only unset '" + name + "'
- Cannot create table . with transactional mode with…
- Cannot drop keyspace
- Cannot drop keyspace
AI-assisted analysis of apache/cassandra@88fd0f6a0e (2026-09-10).
Data as JSON: /api/errors/09406de0ecaa0fbf.
Report an issue: GitHub.
Appendix: source
Thrown at src/java/org/apache/cassandra/db/virtual/AccordDebugKeyspace.java:918
.collect(Collectors.toList());
ConsensusMigrationState snapshot = ClusterMetadata.current().consensusMigrationState;
Collection<TableMigrationState> tableStates = snapshot.tableStatesFor(tableIDs);
return data(tableStates);
}
private SimpleDataSet data(Collection<TableMigrationState> tableStates)
{
SimpleDataSet result = new SimpleDataSet(metadata());
for (TableMigrationState state : tableStates)
{
TableMetadata table = Schema.instance.getTableMetadata(state.tableId);
if (table == null)
{
logger.warn("Table {}.{} (id: {}) no longer exists. It may have been dropped.",
state.keyspaceName, state.tableName, state.tableId);
continue;
}
result.row(state.keyspaceName, state.tableName);
result.column("table_id", state.tableId.asUUID());
result.column("target_protocol", state.targetProtocol.toString());
result.column("transactional_mode", table.params.transactionalMode.toString());
result.column("transactional_migration_from", table.params.transactionalMode.toString());
List<String> primitiveMigratedRanges = state.migratedRanges.stream().map(Objects::toString).collect(toImmutableList());
result.column("migrated_ranges", primitiveMigratedRanges);
List<String> primitiveRepairPendingRanges = state.repairPendingRanges.stream().map(Objects::toString).collect(toImmutableList());
result.column("repair_pending_ranges", primitiveRepairPendingRanges);
Map<Long, List<String>> primitiveRangesByEpoch = new LinkedHashMap<>();
for (Map.Entry<org.apache.cassandra.tcm.Epoch, NormalizedRanges<Token>> entry : state.migratingRangesByEpoch.entrySet())View on GitHub (pinned to 88fd0f6a0e)