apache/seatunnel · error · UnsupportedOperationException

Does not support split requests: subtask

Error message

Does not support split requests: subtask 

What it means

FlussSourceSplitEnumerator.handleSplitRequest rejects the standard SourceReader 'request split' protocol: splits are pushed by the enumerator (assignSplits on registerReader) rather than granted on request. A reader that calls context.sendSplitRequest() causes this UnsupportedOperationException with the requesting subtask id.

Source

Thrown at seatunnel-connectors-v2/connector-fluss/src/main/java/org/apache/seatunnel/connectors/seatunnel/fluss/source/FlussSourceSplitEnumerator.java:197

            if (splits == null || splits.isEmpty()) {
                return;
            }
            splits.forEach(pendingSplits::remove);
            pendingSplits.addAll(splits);
            if (context.registeredReaders().contains(subtaskId)) {
                assignSplits();
            }
        }
    }

    @Override
    public int currentUnassignedSplitSize() {
        return pendingSplits.size();
    }

    @Override
    public void handleSplitRequest(int subtaskId) {
        throw new UnsupportedOperationException(
                "Does not support split requests: subtask " + subtaskId);
    }

    @Override
    public void registerReader(int subtaskId) {
        assignSplits();
    }

    @Override
    public FlussSourceState snapshotState(long checkpointId) {
        synchronized (lock) {
            return new FlussSourceState(new HashSet<>(pendingSplits));
        }
    }

    @Override
    public void notifyCheckpointComplete(long checkpointId) {
        // no-op: read positions are persisted in the split state

View on GitHub (pinned to cf67b549a7)

Solutions

  1. Remove any sendSplitRequest() calls from the reader or custom code; splits are assigned automatically on registerReader
  2. If a reader is idle, verify assignSplits() logic covers all registered subtaskIds
  3. Check for framework/translation layer behavior that requests splits and disable it for this source
  4. Upgrade the connector, if a version adds request-based assignment

Example fix

// before (in reader)
if (splits.isEmpty()) {
  context.sendSplitRequest();
}
// after
if (splits.isEmpty()) {
  // wait: enumerator pushes splits in registerReader/assignSplits
  Thread.sleep(100);
}
Defensive patterns

Strategy: try-catch

Try / catch

try {
  enumerator.handleSplitRequest(subtaskId);
} catch (UnsupportedOperationException e) {
  // do not request splits from this source; rely on push-based assignment
  LOG.debug("Fluss enumerator is push-only: {}", e.getMessage());
}

Prevention

When it happens

Trigger: A FlussSourceReader (or restore path) invokes handleSplitRequest(subtaskId) — typically via ReaderContext.sendSplitRequest() when it finds itself idle and waiting for work — and the enumerator throws immediately.

Common situations: Custom reader modifications or an idle-reader callback triggering split requests against this enumerator; frameworks that assume request/response split assignment call the method during normal runtime.

Related errors


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