apache/seatunnel · error · CatalogException

Failed to truncate table ${tableName} in catalog ${catalogNa

Error message

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

What it means

truncateTable implements truncation by dropping and recreating the index; any failure in either step is wrapped as this CatalogException. Because it composes dropTable and createTable, the error may originate from either sub-operation.

Source

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

    @Override
    public void dropDatabase(TablePath tablePath, boolean ignoreIfNotExists)
            throws DatabaseNotExistException, CatalogException {
        try {
            dropTable(tablePath, ignoreIfNotExists);
        } catch (TableNotExistException ex) {
            throw new DatabaseNotExistException(catalogName, tablePath.getDatabaseName());
        }
    }

    @Override
    public void truncateTable(TablePath tablePath, boolean ignoreIfNotExists) {
        // Delete and recreate the index
        try {
            dropTable(tablePath, ignoreIfNotExists);
            createTable(tablePath, null, false);
        } catch (Exception e) {
            throw new CatalogException(
                    String.format(
                            "Failed to truncate table %s in catalog %s",
                            tablePath.getTableName(), catalogName),
                    e);
        }
    }

    @Override
    public boolean isExistsData(TablePath tablePath) {
        try {
            // First check if the index exists
            if (!ezsClient.checkIndexExist(tablePath.getTableName())) {
                return false;
            }

            // Then check if it has documents
            final List<IndexDocsCount> indexDocsCount =
                    ezsClient.getIndexDocsCount(tablePath.getTableName());

View on GitHub (pinned to cf67b549a7)

Solutions

Check the chained cause to identify whether the drop or the create step failed.
Free disk space / raise the flood-stage watermark so the index is not read-only.
Verify the index can be recreated with the same settings (aliases, templates, mappings).
If a failure left the index dropped, recreate the table manually or via createTable before retrying.

Example fix

// before: index blocked read-only by disk watermark
// PUT _all/_settings {"index.blocks.read_only_allow_delete": null}
// after
// then retry truncateTable(tablePath, false)

Defensive patterns

Strategy: try-catch

Validate before calling

// ensure cluster writable before truncate
GET /_cluster/health?wait_for_status=yellow
GET /_cat/indices/<index>?h=blocks // must not include read_only

Try / catch

try {
    catalog.truncateTable(tablePath, false);
} catch (CatalogException e) {
    // determine if index was dropped; recreate via createTable if needed
    throw e;
}

Prevention

Clear flood-stage read_only blocks before truncating
Ensure index templates/aliases allow recreation
Retry truncate only after verifying the index state

When it happens

Trigger: truncateTable called when dropTable fails (permissions, cluster unavailable, index read-only) or createTable fails (invalid settings/mappings from buildTableOptions, index template conflicts).

Common situations: Cluster read-only due to flood-stage watermark; recreate colliding with an alias or template; transient network failure between drop and create leaving the table missing.

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/f93054e22bdb4a8f. Report an issue: GitHub.