apache/seatunnel · error · IllegalArgumentException
Unsupported plugin type: ${pluginType}
Error message
Unsupported plugin type: ${pluginType} What it means
OptionRulesService maintains a map of PluginDiscovery instances keyed by PluginType. When asking for the discovered plugins of a type that has no registered discovery (only source, sink, and transform are wired), getDiscoveredPlugins throws this IllegalArgumentException listing the offending plugin type.
Source
Thrown at seatunnel-engine/seatunnel-engine-server/src/main/java/org/apache/seatunnel/engine/server/rest/service/OptionRulesService.java:184
.getPluginName()
.equalsIgnoreCase(normalizedPluginName))
.findFirst()
.orElseThrow(
() ->
new NoSuchElementException(
String.format(
"Plugin '%s' not found for type '%s'.",
displayPluginName, pluginType.getType())));
}
private LinkedHashMap<PluginIdentifier, OptionRule> getDiscoveredPlugins(
PluginType pluginType) {
return discoveredPluginsCache.computeIfAbsent(
pluginType,
key -> {
PluginDiscovery<?> pluginDiscovery = pluginDiscoveries.get(key);
if (pluginDiscovery == null) {
throw new IllegalArgumentException(
String.format("Unsupported plugin type: %s", pluginType.getType()));
}
return pluginDiscovery.getPlugins();
});
}
private PluginType parseSupportedPluginType(String pluginTypeText) {
if (StringUtils.isBlank(pluginTypeText)) {
throw new IllegalArgumentException(
String.format("Parameter '%s' cannot be empty.", PARAM_TYPE));
}
String normalizedPluginType = pluginTypeText.trim();
if (StringUtils.equalsIgnoreCase(normalizedPluginType, PluginType.SOURCE.getType())) {
return PluginType.SOURCE;
}
if (StringUtils.equalsIgnoreCase(normalizedPluginType, PluginType.SINK.getType())) {
return PluginType.SINK;
}View on GitHub (pinned to cf67b549a7)
Solutions
- Use only type=source, type=sink, or type=transform in the option-rules request.
- Fix client code to filter the PluginType enum down to the three supported discovery types.
- If a new type is genuinely needed, register a PluginDiscovery for it in pluginDiscoveries (engine-side change).
Example fix
// before curl 'http://host:8080/option-rules?type=processor' // after curl 'http://host:8080/option-rules?type=transform'
Defensive patterns
Strategy: validation
Validate before calling
const SUPPORTED = new Set(["source", "sink", "transform"]);
if (!SUPPORTED.has(type.toLowerCase())) throw new Error("Unsupported plugin type for option-rules: " + type); Try / catch
try { fetchOptionRules(type); } catch (IllegalArgumentException e) { if (e.getMessage().startsWith("Unsupported plugin type")) { fetchOptionRules("transform"); } else throw e; } Prevention
- Restrict client-side type pickers to source/sink/transform.
- Do not iterate the full PluginType enum when generating option-rule requests.
- Pin tooling to the documented option-rules API contract.
When it happens
Trigger: Requesting option rules with type parameter matching a PluginType that exists in the enum but has no PluginDiscovery registered (anything other than source/sink/transform after parsing), e.g. GET /option-rules?type=<unsupported>.
Common situations: Typing an arbitrary value in the option-rules endpoint expecting the full plugin-type enum to be supported; tooling auto-enumerating all PluginType values and hitting the unsupported ones; version drift where a new plugin type is not yet exposed via discovery.
Related errors
- Unsupported plugin type '${pluginType}'. Only 'source', 'sin
- Unsupported action type:
- Dry-run is only supported via CLI
- Parameter 'type' cannot be empty.
- prepare method is not supported
AI-assisted analysis of apache/seatunnel@cf67b549a7 (2026-09-10).
Data as JSON: /api/errors/a469d9ea4078344a.
Report an issue: GitHub.