apache/seatunnel · error · MilvusConnectorException

UNSUPPORTED_OPERATION

UNSUPPORTED_OPERATION

Error message

Unsupported handleSplitRequest: %d

What it means

MilvusSourceSplitEnumerator.handleSplitRequest throws UNSUPPORTED_OPERATION because the Milvus source uses a push-based split assignment model: the enumerator assigns splits proactively and readers never request them. Any call to handleSplitRequest is a protocol violation by the framework or a custom extension.

Source

Thrown at seatunnel-connectors-v2/connector-milvus/src/main/java/org/apache/seatunnel/connectors/seatunnel/milvus/source/MilvusSourceSplitEnumerator.java:239

                        subtaskId,
                        splits);
            }
        }
        log.info("Add back splits {} to MilvusSourceSplitEnumerator.", splits.size());
    }

    private void addPendingSplit(Collection<MilvusSourceSplit> splits, int ownerReader) {
        pendingSplits.computeIfAbsent(ownerReader, r -> new ArrayList<>()).addAll(splits);
    }

    @Override
    public int currentUnassignedSplitSize() {
        return pendingTables.isEmpty() && pendingSplits.isEmpty() ? 0 : 1;
    }

    @Override
    public void handleSplitRequest(int subtaskId) {
        throw new MilvusConnectorException(
                CommonErrorCodeDeprecated.UNSUPPORTED_OPERATION,
                String.format("Unsupported handleSplitRequest: %d", subtaskId));
    }

    @Override
    public void registerReader(int subtaskId) {
        log.info("Register reader {} to MilvusSourceSplitEnumerator.", subtaskId);
        if (!pendingSplits.isEmpty()) {
            assignSplit(Collections.singletonList(subtaskId));
        }
    }

    @Override
    public MilvusSourceState snapshotState(long checkpointId) throws Exception {
        synchronized (stateLock) {
            return new MilvusSourceState(
                    new ArrayList<>(pendingTables),
                    new HashMap<>(pendingSplits),

View on GitHub (pinned to cf67b549a7)

Solutions

  1. Do not call handleSplitRequest — rely on the enumerator's automatic split assignment to registered readers
  2. Check whether a customized SourceReader or translation (Flink/Spark) layer is incorrectly invoking split requests
  3. Verify engine/connector version compatibility — update SeaTunnel if a framework regression issues requests
  4. If you extended the source, implement assignment via the enumerator context, not request/response

Example fix

// before: reader-side custom code forcing assignment
enumerator.handleSplitRequest(subtaskId);
// after: register the reader and let the enumerator assign
enumerator.registerReader(subtaskId); // enumerator pushes splits via context.assignSplit
Defensive patterns

Strategy: try-catch

Try / catch

// This should never be caught in application code — it signals a framework misuse.
// Fix the caller instead of guarding:
// before
enumerator.handleSplitRequest(subtaskId);
// after
enumerator.registerReader(subtaskId);

Prevention

When it happens

Trigger: A reader (or engine code path) calls handleSplitRequest(subtaskId) on the Milvus split enumerator instead of waiting for addSplitBack/assigned splits via the standard SourceReader event flow.

Common situations: Custom modifications to the SeaTunnel source framework, running this enumerator with a translation layer or engine version that issues split requests, or a custom reader implementation calling handleSplitRequest directly.

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/7491ffba80649ea0. Report an issue: GitHub.