apache/seatunnel · error · ConfigCheckException

${location(pluginType, configIndex, factoryId)} does not sup

Error message

${location(pluginType, configIndex, factoryId)} does not support processing inputs with different schemas. Expected table ${expected.tableId} but found table ${catalogTable.tableId}.

What it means

checkCatalogTableTypesEqual verifies that all CatalogTables feeding a plugin (a transform's inputs or a sink's merged inputs) have identical SeaTunnelRowType schemas. If any table's row type differs from the first table's, a ConfigCheckException is thrown reporting the expected and mismatching TableIds. This prevents plugins from receiving inputs with incompatible column layouts.

Source

Thrown at seatunnel-core/seatunnel-starter/src/main/java/org/apache/seatunnel/core/starter/seatunnel/command/DryRunConnectValidator.java:429

        }
        ReadonlyConfig schemaConfig = ReadonlyConfig.fromMap(schemaMap);
        return schemaConfig.getOptional(ColumnOptions.COLUMNS).isPresent()
                || entryConfig.getOptional(FieldOptions.FIELDS).isPresent()
                || schemaConfig.getOptional(ColumnOptions.METADATA_TABLE_ID).isPresent();
    }

    private void checkCatalogTableTypesEqual(
            List<CatalogTable> catalogTables,
            PluginType pluginType,
            int configIndex,
            String factoryId) {
        if (catalogTables.isEmpty()) {
            return;
        }
        CatalogTable expected = catalogTables.get(0);
        for (CatalogTable catalogTable : catalogTables) {
            if (!expected.getSeaTunnelRowType().equals(catalogTable.getSeaTunnelRowType())) {
                throw new ConfigCheckException(
                        location(pluginType, configIndex, factoryId)
                                + " does not support processing inputs with different schemas. "
                                + "Expected table "
                                + expected.getTableId()
                                + " but found table "
                                + catalogTable.getTableId()
                                + ".");
            }
        }
    }

    private List<String> getInputIds(ReadonlyConfig config) {
        return config.getOptional(PLUGIN_INPUT).orElse(Collections.singletonList(DEFAULT_ID));
    }

    private <T> T findLast(LinkedHashMap<?, T> map) {
        if (map.isEmpty()) {
            throw new ConfigCheckException(

View on GitHub (pinned to cf67b549a7)

Solutions

  1. Align the schemas: make each upstream select/project the same columns with the same types and order.
  2. Insert a transform (e.g. SQL/FieldMapper) per branch to normalize columns before they converge.
  3. If a source table changed, update the config or pin the query to an explicit column list.

Example fix

// before
source {
  Jdbc { query = "select id, name from users"; plugin_output = "a" }
  Jdbc { query = "select id, email from users2"; plugin_output = "b" }
}
// after
source {
  Jdbc { query = "select id, name from users"; plugin_output = "a" }
  Jdbc { query = "select id, name from users2"; plugin_output = "b" }
}
Defensive patterns

Strategy: validation

Validate before calling

// compare inferred schemas of all inputs to a plugin before validating
const schemas = inputs.map(i => i.seaTunnelRowType);
const first = JSON.stringify(schemas[0]);
if (schemas.some(s => JSON.stringify(s) !== first)) {
  throw new Error("Inputs have different schemas; normalize with a transform before merging");
}

Try / catch

try { validateConf(conf, DryRun.CONNECT); } catch (ConfigCheckException e) { if (e.getMessage().contains("does not support processing inputs with different schemas")) { addSchemaNormalizingTransforms(conf); } else { throw e; } }

Prevention

When it happens

Trigger: During validateTransform or resolveSinkInputTables when a plugin declares multiple plugin_input upstreams whose inferred schemas differ in column names, types, or order — e.g. two JDBC sources reading tables with different columns merged into one sink.

Common situations: Union-style configs joining heterogeneous tables into one sink; upstream schema drift after a source table was altered; copy-pasted source blocks with different column lists.

Understand the failure class

Background: Schema validation failed / invalid input schema: payload rejected because its shape doesn't match the expected schema — this error's family across 28 libraries.

Related errors


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