What causes "No lambda method found." in apache/flink?

Replace the lambda with an anonymous inner class that explicitly implements the interface.

apache/flink · error · TypeExtractionException

No lambda method found.

Error message

No lambda method found.

What it means

Thrown by TypeExtractionUtils.getLambdaExecutable when the serialized lambda's implementing method or constructor cannot be found in the implementing class. After successfully serializing the lambda (via writeReplace) and loading the implementing class, the method name and descriptor from SerializedLambda are matched against all declared methods. If none match, this TypeExtractionException is thrown.

Source

Thrown at flink-core/src/main/java/org/apache/flink/api/java/typeutils/TypeExtractionUtils.java:158

            if (methodName.equals("<init>")) {
                Constructor<?>[] constructors = implClass.getDeclaredConstructors();
                for (Constructor<?> constructor : constructors) {
                    if (getConstructorDescriptor(constructor).equals(methodSig)) {
                        return new LambdaExecutable(constructor);
                    }
                }
            }
            // find method
            else {
                List<Method> methods = getAllDeclaredMethods(implClass);
                for (Method method : methods) {
                    if (method.getName().equals(methodName)
                            && getMethodDescriptor(method).equals(methodSig)) {
                        return new LambdaExecutable(method);
                    }
                }
            }
            throw new TypeExtractionException("No lambda method found.");
        } catch (Exception e) {
            throw new TypeExtractionException(
                    "Could not extract lambda method out of function: "
                            + e.getClass().getSimpleName()
                            + " - "
                            + e.getMessage(),
                    e);
        }
    }

    /**
     * Extracts type from given index from lambda. It supports nested types.
     *
     * @param baseClass SAM function that the lambda implements
     * @param exec lambda function to extract the type from
     * @param lambdaTypeArgumentIndices position of type to extract in type hierarchy
     * @param paramLen count of total parameters of the lambda (including closure parameters)
     * @param baseParametersLen count of lambda interface parameters (without closure parameters)

View on GitHub (pinned to 2f3c205e92)

Solutions

Replace the lambda with an anonymous inner class that explicitly implements the interface.
Ensure the implementing class jar at runtime matches the compiled version exactly.
Explicitly specify the type information using TypeInformation.of(...) or .returns(...) instead of relying on lambda extraction.
Check for bytecode manipulation agents (ASM, ByteBuddy, coverage tools) that may alter method names.

Example fix

// before
ds.map(x -> x.toLowerCase())
// after
ds.map(new MapFunction<String, String>() {
    @Override
    public String map(String x) { return x.toLowerCase(); }
}).returns(TypeInformation.of(String.class));

Defensive patterns

Strategy: fallback

Try / catch

try {
    ds.map(lambdaFn);
} catch (InvalidTypesException e) {
    // fall back to anonymous class with explicit type
    ds.map(new MapFunction<IN, OUT>() {
        public OUT map(IN value) { return lambdaFn.apply(value); }
    }).returns(TypeInformation.of(OUT.class));
}

Prevention

Prefer anonymous classes over lambdas when generics are involved.
Always chain .returns(TypeInformation.of(...)) after lambda transformations.
Ensure runtime classloader matches compile-time classloader for lambda implementing classes.

When it happens

Trigger: Type erasure or compiler optimizations remove or rename the lambda's implementing method. A custom classloader loads a different version of the implementing class than the one that compiled the lambda. Obfuscated or instrumented bytecode where method names or signatures differ at runtime from compile time.

Common situations: Running in an environment with aggressive bytecode manipulation (e.g. certain AOP frameworks, code coverage tools, or obfuscators). Deploying a jar compiled with a different JDK version that emits different synthetic method names. Lambda capturing a bridge method due to type variable bounds.

Related errors

AI-assisted analysis of apache/flink@2f3c205e92 (2026-08-14). Data as JSON: /api/errors/976ba3c23f9a6529. Report an issue: GitHub.