Skip to content

BackgroundFunctionExecutor.java failes to detect type when sub-classed #95

@bhoogter

Description

@bhoogter

Error Condition

Exception in thread "main" java.lang.RuntimeException: Could not determine the payload type for BackgroundFunction of type com.example.MyFunctionHandler; must implement BackgroundFunction for some T at com.google.cloud.functions.invoker.BackgroundFunctionExecutor.forClass(BackgroundFunctionExecutor.java:140) at com.google.cloud.functions.invoker.BackgroundFunctionExecutor.forClass(BackgroundFunctionExecutor.java:113) at com.google.cloud.functions.invoker.runner.Invoker.startServer(Invoker.java:256) at com.google.cloud.functions.invoker.runner.Invoker.main(Invoker.java:127)

Occurs when BackgroundFunction<T> is subclassed:

public abstract class MyExtendedBackgroundFunction<T> implements BackgroundFunction<T>

and

public class MyFunctionHandler extends MyExtendedBackgroundFunction<MyReturnType>

In the class mentioned, the following function fails to detect sub-classed BackgroundFunction type:

static Optional<Type> backgroundFunctionTypeArgument(Class<? extends BackgroundFunction<?>> functionClass) {    
// If this is BackgroundFunction<Foo> then the user must have implemented a method    
// accept(Foo, Context), so we look for that method and return the type of its first argument.    
// We must be careful because the compiler will also have added a synthetic method    
// accept(Object, Context).    
return Arrays.stream(functionClass.getMethods())        
.filter(m -> m.getName().equals("accept") &amp;&amp; m.getParameterCount() == 2            && m.getParameterTypes()[1] == Context.class            &amp;&amp; m.getParameterTypes()[0] != Object.class)        
.map(m -> m.getGenericParameterTypes()[0])        
.findFirst();  
}

This fails for described MyFunctionHandler.

The intent is to add common boilerplate handling for a couple of functions which is common to all. A separate abstract function is employed, but the function fails to load because the type is not determined.

Temporary workaround is to re-implement accept() with the type in the sub-classed object with the type, but is inelegant.

Metadata

Metadata

Assignees

No one assigned

    Labels

    P3bugSomething isn't working

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions