apache/druid · error · ISE
Table %s: not found
Error message
Table %s: not found
What it means
Inside alterTableProperties, after acquiring the table lock, the UPDATE of the properties column returned 0 affected rows. Since the lock should guarantee existence, this is flagged as an internal invariant violation (ISE) rather than an expected error — the row vanished unexpectedly or the id didn't match.
Source
Thrown at extensions-core/druid-catalog/src/main/java/org/apache/druid/catalog/storage/sql/SQLCatalogManager.java:401
} else {
throw tableNotFound(id);
}
final TableSpec revised = transform.apply(TableMetadata.of(id, tableSpec));
if (revised == null) {
handle.rollback();
return null;
}
final long updateTime = System.currentTimeMillis();
final int updateCount = handle
.createStatement(statement(UPDATE_PROPERTIES_STMT))
.bind(SCHEMA_NAME_COL, id.schema())
.bind(TABLE_NAME_COL, id.name())
.bind(PROPERTIES_COL, JacksonUtils.toBytes(jsonMapper, revised.properties()))
.bind(UPDATE_TIME_COL, updateTime)
.execute();
if (updateCount == 0) {
// Should never occur because we're holding a lock.
throw new ISE("Table %s: not found", id.sqlName());
}
handle.commit();
return TableMetadata.forUpdate(id, updateTime, revised);
}
catch (Exception e) {
handle.rollback();
throw e;
}
}
}
);
if (result == null) {
return 0;
}
sendUpdate(EventType.PROPERTY_UPDATE, result);
return result.updateTime();
}
catch (CallbackFailedException e) {View on GitHub (pinned to 9b90983fd2)
Solutions
- Check for concurrent deleteTable calls and ensure the table lock covers the entire alter/delete lifecycle.
- Confirm the TableId matches exactly the name used at creation (case/whitespace).
- Inspect the catalog table in the DB to see whether the row exists and under what name.
- If caused by tooling modifying the DB out-of-band, restrict direct DB edits and re-create the table.
Example fix
// before
manager.alterTableProperties(id, revised); // ISE: Table X: not found
// after
if (manager.readTable(id) != null) {
manager.alterTableProperties(id, revised);
} Defensive patterns
Strategy: validation
Validate before calling
if (manager.readTable(id) == null) {
throw new IllegalStateException("Table not found before alterTableProperties: " + id.sqlName());
} Try / catch
try {
manager.alterTableProperties(id, revised);
} catch (ISE e) {
if (e.getMessage().contains("not found")) {
// reconcile: re-read table, check for concurrent delete
}
} Prevention
- Verify the exact TableId used at creation (case, whitespace).
- Serialize deletes and property alters under the same lock.
- Avoid direct manual edits to the catalog metadata DB.
When it happens
Trigger: alterTableProperties(id, ...) under lock where the UPDATE ... WHERE name matches zero rows: the table was concurrently deleted despite the lock, or the TableId name mismatches the stored name.
Common situations: Concurrent dropTable racing the locked alter (lock gap); DB row manually deleted; passing an id with different case/normalization than what createTable stored.
Understand the failure class
Background: "This is a bug, please report it": internal invariant violations, unreachable panics, and SNH errors explained — this error's family across 47 libraries.
Related errors
- Cannot translate sqlTypeName[%s] to Druid type for field[%s]
- Invalid parameter type:
- Unsupported query result format:
- Cannot translate sqlTypeName[%s] to Druid type for field[%s]
- requires a ThetaSketch as the argument
AI-assisted analysis of apache/druid@9b90983fd2 (2026-09-07).
Data as JSON: /api/errors/fea5d650b9f407c7.
Report an issue: GitHub.