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

  1. Use only type=source, type=sink, or type=transform in the option-rules request.
  2. Fix client code to filter the PluginType enum down to the three supported discovery types.
  3. 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

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


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