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
- Use a supported startup.mode (initial, earliest, latest, or specific timestamp/offset) instead of one requiring committed offsets
- Check the specific connector's docs for supported startup modes and offset types
- Override committedOffset() in a custom OffsetFactory if you own the dialect implementation
- 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
- Check connector docs for supported startup modes before using committed offsets
- Prefer explicit specific-offset config over committed-offset defaults
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
- not supported create new Offset by filename and position.
- not supported create new Offset by timestamp.
- UNSUPPORTED_OPERATION
- not supported create new Offset by filename and position.
- not supported create new Offset by timestamp.
AI-assisted analysis of apache/seatunnel@cf67b549a7 (2026-09-10).
Data as JSON: /api/errors/8421da180c1f0372.
Report an issue: GitHub.