apache/seatunnel · error · UnsupportedOperationException

Gitlab source connector not support unbounded operation

Error message

Gitlab source connector not support unbounded operation

What it means

The Gitlab source connector only supports bounded (batch) reads. SeaTunnelSource.getBoundedness() reports the connector's execution mode to the engine; when the job is launched in STREAMING mode the connector has no incremental/polling logic, so it throws UnsupportedOperationException instead of returning a boundedness value. It returns BOUNDED only when the job mode is BATCH.

Source

Thrown at seatunnel-connectors-v2/connector-http/connector-http-gitlab/src/main/java/org/apache/seatunnel/connectors/seatunnel/gitlab/source/GitlabSource.java:51

public class GitlabSource extends HttpSource {
    private final GitlabSourceParameter gitlabSourceParameter = new GitlabSourceParameter();

    public GitlabSource(ReadonlyConfig pluginConfig) {
        super(pluginConfig);
        this.gitlabSourceParameter.buildWithConfig(pluginConfig);
    }

    @Override
    public String getPluginName() {
        return "Gitlab";
    }

    @Override
    public Boundedness getBoundedness() {
        if (JobMode.BATCH.equals(jobContext.getJobMode())) {
            return Boundedness.BOUNDED;
        }
        throw new UnsupportedOperationException(
                "Gitlab source connector not support unbounded operation");
    }

    @Override
    public AbstractSingleSplitReader<SeaTunnelRow> createReader(
            SingleSplitReaderContext readerContext) throws Exception {
        return new HttpSourceReader(
                this.gitlabSourceParameter,
                readerContext,
                this.deserializationSchema,
                jsonField,
                contentField);
    }
}

View on GitHub (pinned to cf67b549a7)

Solutions

Set job.mode = BATCH in the source job config (env block) before running.
Use a different connector that supports streaming (e.g. a polling HTTP source or CDC connector) if continuous ingestion from Gitlab is required.
Check the submitted config file's env section; remove any job.mode = streaming line.

Example fix

// before
env {
  job.mode = "STREAMING"
}
source {
  Gitlab { ... }
}

// after
env {
  job.mode = "BATCH"
}
source {
  Gitlab { ... }
}

Defensive patterns

Strategy: validation

Validate before calling

// In your job config, before submission:
// env { job.mode = "BATCH" }
String jobMode = config.getString("job.mode");
if (!"BATCH".equalsIgnoreCase(jobMode)) {
    throw new IllegalArgumentException("Gitlab source requires job.mode = BATCH, got: " + jobMode);
}

Prevention

Always declare job.mode explicitly in the env block of every job config.
Keep separate config templates for batch vs streaming pipelines.
Remember HTTP-based sources (Gitlab/Jira/PostHog) are batch-only in SeaTunnel.

When it happens

Trigger: Submitting a SeaTunnel job with mode = STREAMING (or omitting job.mode so the engine defaults to streaming) while the source is the Gitlab connector; the engine calls getBoundedness() during job initialization and immediately throws.

Common situations: Users copy a streaming config (e.g. written for Kafka/CDC connectors) and swap in Gitlab as the source; also happens in dev/test scripts that default env='run' with streaming job mode.

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