apache/seatunnel · error · UnsupportedOperationException

not supported create new Offset by committed offset.

Error message

not supported create new Offset by committed offset.

What it means

OffsetFactory.committedOffset() is an optional capability: by default it throws UnsupportedOperationException because only some connector dialects can build an Offset from a source's committed offset. Calling it on a factory that doesn't support committed-offset-based startup positions fails immediately.

Source

Thrown at seatunnel-connectors-v2/connector-cdc/connector-cdc-base/src/main/java/org/apache/seatunnel/connectors/cdc/base/source/offset/OffsetFactory.java:33

 * limitations under the License.
 */

package org.apache.seatunnel.connectors.cdc.base.source.offset;

import java.io.Serializable;
import java.util.Map;

public abstract class OffsetFactory implements Serializable {
    public OffsetFactory() {}

    public abstract Offset earliest();

    public abstract Offset neverStop();

    public abstract Offset latest();

    public Offset committedOffset() {
        throw new UnsupportedOperationException(
                "not supported create new Offset by committed offset.");
    }

    public abstract Offset specific(Map<String, String> offset);

    public abstract Offset specific(String filename, Long position);

    public abstract Offset timestamp(long timestamp);
}

View on GitHub (pinned to cf67b549a7)

Solutions

  1. Use a supported startup.mode (initial, earliest, latest, or specific timestamp/offset) instead of one requiring committed offsets
  2. Check the specific connector's docs for supported startup modes and offset types
  3. Override committedOffset() in a custom OffsetFactory if you own the dialect implementation
  4. Upgrade SeaTunnel/connector version in case committed-offset support was added for your dialect

Example fix

// before
// startup: { mode: "committed" }   // unsupported by this connector's OffsetFactory
// after
// startup: { mode: "specific", "specific-offset-file": "mysql-bin.000010", "specific-offset-pos": 4321 }
Defensive patterns

Strategy: validation

Validate before calling

// Only use committed-offset startup when the dialect supports it:
if (offsetFactory.getClass().getMethod("committedOffset").getDeclaringClass() == OffsetFactory.class) {
    throw new IllegalArgumentException("This connector does not support committed-offset startup");
}

Try / catch

try { return factory.committedOffset(); }
catch (UnsupportedOperationException e) { return factory.latest(); }

Prevention

When it happens

Trigger: getStartupOffset() or shouldReuseCheckpointedStartupOffsetAfterRestore() calls committedOffset() on a dialect whose OffsetFactory hasn't overridden it — i.e. a startup.mode/restore path relying on committed offsets with a dialect that can't produce them.

Common situations: Using a startup mode that depends on committed offsets with a CDC connector (e.g. certain SQL Server/Oracle setups) that lacks the feature; upgrading a job where the restore path now requests committed offsets for an unsupported dialect.

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


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