apache/seatunnel · warning

Unsupported resolve schemaChangeEvent {}, just skip.

Error message

Unsupported resolve schemaChangeEvent {}, just skip.

What it means

After asking the schema resolver to translate a DDL change record, the resolver returned null — meaning it recognized the event but could not produce a supported schema change. The connector logs this warning (including the record) and skips the event rather than failing the job, so the sink schema does not receive the change.

Source

Thrown at seatunnel-connectors-v2/connector-cdc/connector-cdc-base/src/main/java/org/apache/seatunnel/connectors/cdc/debezium/row/SeaTunnelRowDebeziumDeserializeSchema.java:147

    private void deserializeSchemaChangeRecord(
            SourceRecord record, Collector<SeaTunnelRow> collector) {
        SchemaChangeEvent schemaChangeEvent = null;
        try {
            if (schemaChangeResolver != null) {
                schemaChangeEvent = schemaChangeResolver.resolve(record, tables);
            }
        } catch (SchemaEvolutionException e) {
            // A resolver uses SchemaEvolutionException only when continuing would make the
            // produced row schema diverge from the source relation. Keep generic parser failures
            // backward-compatible, but fail fast for an explicitly classified schema error.
            throw e;
        } catch (Exception e) {
            log.warn("Failed to resolve schemaChangeEvent, just skip.", e);
            return;
        }
        if (schemaChangeEvent == null) {
            log.warn("Unsupported resolve schemaChangeEvent {}, just skip.", record);
            return;
        }

        // Filter before updating the produced schema, so the produced row shape stays in lockstep
        // with the (filtered) sink schema. Only surviving events are applied below.
        if (schemaChangeEventFilter != null) {
            schemaChangeEvent = schemaChangeEventFilter.filter(schemaChangeEvent);
        }
        if (schemaChangeEvent == null) {
            log.debug(
                    "Schema change event is fully filtered out by schema-changes.include/exclude, not applied to schema and not sent downstream.");
            return;
        }

        boolean tableExist = false;
        for (int i = 0; i < tables.size(); i++) {
            CatalogTable changeBefore = tables.get(i);
            if (!schemaChangeEvent.tablePath().equals(changeBefore.getTablePath())) {

View on GitHub (pinned to cf67b549a7)

Solutions

1. Inspect the logged record to identify which DDL event was unsupported and whether its table is in your pipeline.
2. If the event belongs to an unrelated table, the skip is expected and safe.
3. If the change is needed downstream, apply it manually to the sink and restart the job so the reader matches the new schema.
4. Configure or extend the schemaChangeEventFilter/resolver so supported events are handled instead of returned as null.
5. Upgrade the connector if the unsupported event kind is newly supported upstream.

Example fix

// before: event silently skipped, sink misses the column
if (schemaChangeEvent == null) {
    log.warn("Unsupported resolve schemaChangeEvent {}, just skip.", record);
    return;
}
// after: surface the unsupported event so drift is visible/trackable
if (schemaChangeEvent == null) {
    throw new UnsupportedOperationException(
        "Unsupported schema change event for table " + tableId + ": " + record);
}

// check resolver support before enabling schema evolution in the pipeline
if (!resolver.supports(ddlOperation, tableId)) {
    log.warn("Resolver does not support {} on {}; sink must be updated manually", ddlOperation, tableId);
}

boolean isHandled(SchemaChangeEvent e) { return e != null; }

SchemaChangeEvent evt = resolver.resolve(record);
if (evt == null) {
    log.warn("Unsupported schema change for {} — apply manually or upgrade connector", tableId);
    return; // or throw if silent drift is unacceptable
}

When it happens

Trigger: deserializeSchemaChangeRecord (invoked from deserialize for DDL records) receives a schema change whose operation/table/type is not supported by the configured SchemaChangeEventResolver, so resolve() returns null instead of throwing.

Common situations: ALTER TABLE operations the resolver deliberately does not support (e.g. unsupported column types); DDL on tables not part of the pipeline's table list; events filtered out by schemaChangeEventFilter upstream leaving unsupported kinds; connector lacking support for a database-specific change kind.

Understand the failure class

Background: UnsupportedOperationException and "is not supported" errors: when a library deliberately refuses a call — this error's family across 30 libraries.

Related errors

• Failed to resolve schemaChangeEvent, just skip.
• Unable to instantiate the database history class " + config.
• Data change record shouldn't use READ operation, the the rec
• The table changes should only have one element
• Unknown table change type:

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