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
- Do not call handleSplitRequest — rely on the enumerator's automatic split assignment to registered readers
- Check whether a customized SourceReader or translation (Flink/Spark) layer is incorrectly invoking split requests
- Verify engine/connector version compatibility — update SeaTunnel if a framework regression issues requests
- 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
- Never call handleSplitRequest on push-based enumerators
- Use stock SeaTunnel SourceReader implementations for the Milvus source
- Test custom engine/translation modifications against supported source semantics
- Keep engine and connector versions aligned
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
- OPERATION_NOT_SUPPORTED
- LIST_PARTITIONS_FAILED
- The single-split reader don't support reading multiple split
- CommonErrorCodeDeprecated.UNSUPPORTED_OPERATION
- CommonErrorCodeDeprecated.ILLEGAL_ARGUMENT
AI-assisted analysis of apache/seatunnel@cf67b549a7 (2026-09-10).
Data as JSON: /api/errors/7491ffba80649ea0.
Report an issue: GitHub.