apache/seatunnel · error · CatalogException

Dropping database %s exception.

Error message

Dropping database %s exception.

What it means

After verifying the database is empty, HudiCatalog.dropDatabase() deletes the database directory via the Hadoop FileSystem. If that filesystem operation throws IOException (NameNode unreachable, permission denied, network failure to S3, etc.), it is rethrown as a CatalogException with this message and the original cause attached. The drop did not complete; inspect the wrapped cause.

Source

Thrown at seatunnel-connectors-v2/connector-hudi/src/main/java/org/apache/seatunnel/connectors/seatunnel/hudi/catalog/HudiCatalog.java:319

            if (ignoreIfNotExists) {
                return;
            } else {
                throw new DatabaseNotExistException(catalogName, tablePath.getDatabaseName());
            }
        }

        List<String> tables = listTables(tablePath.getDatabaseName());
        if (!tables.isEmpty()) {
            throw new CatalogException(
                    String.format(
                            "Database %s not empty, can't drop it.", tablePath.getDatabaseName()));
        }

        Path dbPath = new Path(tableParentDfsPath, tablePath.getDatabaseName());
        try {
            fs.delete(dbPath, true);
        } catch (IOException e) {
            throw new CatalogException(
                    String.format("Dropping database %s exception.", tablePath.getDatabaseName()),
                    e);
        }
    }

    private TableSchema convertSchema(
            TableSchema.Builder tableSchemaBuilder, HoodieTableConfig tableConfig) {
        if (tableConfig.getTableCreateSchema().isPresent()) {
            Schema schema = tableConfig.getTableCreateSchema().get();
            List<Schema.Field> fields = schema.getFields();
            for (Schema.Field field : fields) {
                tableSchemaBuilder.column(
                        PhysicalColumn.of(
                                field.name(),
                                convertSeaTunnelType(field.name(), field.schema()),
                                (Long) null,
                                true,
                                null,

View on GitHub (pinned to cf67b549a7)

Solutions

  1. Inspect the wrapped cause exception to identify the filesystem failure (connection refused, permission denied, auth).
  2. Verify the HDFS/S3 connection settings and credentials used by the SeaTunnel job; test fs delete access with a small path.
  3. Retry the dropDatabase after connectivity/auth is restored — the pre-check guarantees the DB is empty so a retry is safe.
  4. Check HDFS permissions (hdfs dfs -rmdir) for the warehouse directory for the user running SeaTunnel.
Defensive patterns

Strategy: retry

Validate before calling

// pre-check connectivity
FileSystem fs = FileSystem.get(conf);
fs.exists(new Path(warehousePath)); // throws if FS unreachable

Try / catch

try {
    catalog.dropDatabase(tablePath);
} catch (CatalogException e) {
    if (e.getCause() instanceof IOException) {
        // log cause, backoff and retry; verify DB emptiness before retry
    } else throw e;
}

Prevention

When it happens

Trigger: fs.delete(dbPath, true) on the database's DFS path throws IOException — e.g. HDFS NameNode unavailable, S3 credentials/expiry, missing permission on the parent path, or transient network failure.

Common situations: Cluster connectivity problems during a drop; misconfigured fs.defaultFS or S3A endpoint; Kerberos/token expiry; HDFS permission denied for the job user on the warehouse path.

Related errors


AI-assisted analysis of apache/seatunnel@cf67b549a7 (2026-09-10). Data as JSON: /api/errors/ad1796a14d5f1734. Report an issue: GitHub.