apache/dolphinscheduler · error · IllegalArgumentException

Parameter types: " + Lists.newArrayList(standardRpcRequest.g

Error message

Parameter types: " + Lists.newArrayList(standardRpcRequest.getArgsTypes()) + " do not match the method signature.

What it means

JdkDynamicServerHandler.processReceived dispatches an incoming RPC to the target interface method via a MethodInvoker. Before invoking, it validates the deserialized argument type names against the actual method signature; a mismatch throws IllegalArgumentException so the caller gets a failed RPC response instead of a reflective crash.

Source

Thrown at dolphinscheduler-extract/dolphinscheduler-extract-base/src/main/java/org/apache/dolphinscheduler/extract/base/server/JdkDynamicServerHandler.java:107

                StandardRpcResponse iRpcResponse =
                        StandardRpcResponse.fail("Cannot find the ServerMethodInvoker of " + methodIdentifier);
                TransporterHeader transporterHeader =
                        TransporterHeader.of(transporter.getHeader().getOpaque(), methodIdentifier);
                Transporter response = Transporter.of(transporterHeader, iRpcResponse);
                channel.writeAndFlush(response);
                return;
            }
            methodInvokeExecutor.execute(() -> {
                StandardRpcResponse iRpcResponse;
                try {
                    StandardRpcRequest standardRpcRequest =
                            JsonSerializer.deserialize(transporter.getBody(), StandardRpcRequest.class);
                    Object[] args;
                    if (standardRpcRequest.getArgs() == null || standardRpcRequest.getArgs().length == 0) {
                        args = null;
                    } else {
                        if (!methodInvoker.isParameterTypeValidated(standardRpcRequest.getArgsTypes())) {
                            throw new IllegalArgumentException(
                                    "Parameter types: " + Lists.newArrayList(standardRpcRequest.getArgsTypes())
                                            + " do not match the method signature.");
                        }
                        args = new Object[standardRpcRequest.getArgs().length];
                        for (int i = 0; i < standardRpcRequest.getArgs().length; i++) {
                            args[i] = JsonSerializer.deserialize(standardRpcRequest.getArgs()[i],
                                    standardRpcRequest.getArgsTypes()[i]);
                        }
                    }
                    Object result = methodInvoker.invoke(args);
                    if (result == null) {
                        iRpcResponse = StandardRpcResponse.success(null, null);
                    } else {
                        iRpcResponse = StandardRpcResponse.success(JsonSerializer.serialize(result), result.getClass());
                    }
                } catch (Throwable e) {
                    log.error("Invoke method {} failed, {}.", methodIdentifier, e.getMessage(), e);
                    iRpcResponse = StandardRpcResponse.fail(e.getMessage());

View on GitHub (pinned to 02eac45a1b)

Solutions

Rebuild/redeploy client and server against the same version of the API interface module
Compare argsTypes sent by the client with the actual method parameter types on the server
Clear stale jars/dependency conflicts so both ends load the identical interface class
Update the client call site to pass arguments matching the current method signature

Example fix

// before
// client interface: TaskClient.dispatch(TaskExecutionContext ctx)
// server interface: TaskClient.dispatch(TaskExecuteContext ctx)  // renamed type
rpcClient.send(TaskClient.class, "dispatch", executionContext);
// after
// align both ends on the same interface type, then
rpcClient.send(TaskClient.class, "dispatch", executionContext); // same TaskExecutionContext on both ends

Defensive patterns

Strategy: validation

Validate before calling

// validate argument types against the target interface method before sending
Class<?>[] expected = targetMethod.getParameterTypes();
String[] sent = request.getArgsTypes();
if (expected.length != sent.length || !java.util.Arrays.equals(
        java.util.Arrays.stream(expected).map(Class::getName).toArray(), sent)) {
    throw new IllegalStateException("RPC arg types do not match " + targetMethod);
}

Try / catch

try {
    Object result = rpcClient.send(iface, method, args);
} catch (Exception e) {
    if (e.getMessage() != null && e.getMessage().contains("do not match the method signature")) {
        // client/server interface mismatch: resync API module versions
    }
    throw e;
}

Prevention

Keep the API interface module at the same version on client and server
Regenerate stubs/SDKs after any interface signature change
Add CI checks that both deployments resolve the same interface class version

When it happens

Trigger: A StandardRpcRequest arrives whose argsTypes array does not match the parameter types of the server-side interface method resolved by method name — e.g. client and server interface definitions differ, or the client sends wrong type descriptors.

Common situations: Client and server built against different versions of the same API interface (parameter type changed); client calling a same-named method with different signature on a stale server; custom SDK generating incorrect argsTypes; classpath conflicts where the interface differs on both ends.

Understand the failure class

Background: Type mismatch errors: IllegalArgumentException, TypeError and type guards across 150 open-source libraries — this error's family across 150 libraries.

Related errors

AI-assisted analysis of apache/dolphinscheduler@02eac45a1b (2026-09-06). Data as JSON: /api/errors/8c5f7f7c355ca190. Report an issue: GitHub.