apache/seatunnel · error · CatalogException

Failed to drop table ${tableName} in catalog ${catalogName}

Error message

Failed to drop table ${tableName} in catalog ${catalogName}

What it means

EasysearchCatalog.dropTable calls ezsClient.dropIndex to delete the underlying index; any exception from the REST call is wrapped in a CatalogException naming the table and catalog. It means the index deletion request failed at the Easysearch cluster level.

Source

Thrown at seatunnel-connectors-v2/connector-easysearch/src/main/java/org/apache/seatunnel/connectors/seatunnel/easysearch/catalog/EasysearchCatalog.java:204

            return;
        }
        ezsClient.createIndex(tablePath.getTableName());
    }

    @Override
    public void dropTable(TablePath tablePath, boolean ignoreIfNotExists)
            throws TableNotExistException, CatalogException {
        checkNotNull(tablePath);
        if (!tableExists(tablePath)) {
            if (!ignoreIfNotExists) {
                throw new TableNotExistException(catalogName, tablePath);
            }
            return;
        }
        try {
            ezsClient.dropIndex(tablePath.getTableName());
        } catch (Exception ex) {
            throw new CatalogException(
                    String.format(
                            "Failed to drop table %s in catalog %s",
                            tablePath.getTableName(), catalogName),
                    ex);
        }
    }

    @Override
    public void createDatabase(TablePath tablePath, boolean ignoreIfExists)
            throws DatabaseAlreadyExistException, CatalogException {
        try {
            createTable(tablePath, null, ignoreIfExists);
        } catch (TableAlreadyExistException ex) {
            throw new DatabaseAlreadyExistException(catalogName, tablePath.getDatabaseName());
        }
    }

    @Override

View on GitHub (pinned to cf67b549a7)

Solutions

Read the wrapped cause for the real HTTP error (403, 404, cluster blocked).
Check disk watermarks: a full disk makes Easysearch set indices read-only and reject writes/deletes.
Verify the catalog user has delete_index privileges on the target index.
Retry once the cluster is reachable; for truncateTable, ensure both dropTable and createTable can succeed.

Example fix

// before: user without privileges
String username = "reader"; // 403 on delete index
// after
String username = "admin"; // or grant delete_index to 'reader' role

Defensive patterns

Strategy: try-catch

Validate before calling

// preflight: index exists and user can delete
HEAD /<index>
GET /_security/user/<user> // verify delete_index privilege

Try / catch

try {
    catalog.dropTable(tablePath, false);
} catch (CatalogException e) {
    Throwable cause = e.getCause();
    // handle ResponseException with status 403/404/503 accordingly
    throw e;
}

Prevention

Grant delete_index privilege to the catalog user
Monitor disk watermarks to avoid read_only blocks
Use ignoreIfNotExists=true when the table may not exist

When it happens

Trigger: dropTable, or its callers dropDatabase/truncateTable, invoked while the cluster rejects the delete index call: index missing when ignoreIfNotExists=false path passes but cluster errors anyway, security permissions deny delete, or cluster unavailable.

Common situations: User lacks delete-index privileges; cluster in read-only mode (disk watermark exceeded); connection reset mid-request; calling truncateTable which delegates to dropTable and surfaces this error.

Understand the failure class

Background: "API error: {status}" and "HTTP 401/403/404/429/5xx" errors: non-2xx HTTP responses explained — this error's family across 27 libraries.

Related errors

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