Flux<com.amazonaws.services.lambda.runtime.events.*> is ignored by AWSLambdaUtils.isSupportedAWSType

[davidmelia]

Describe the bug
In Spring Cloud AWS Function 2021.0.5 or 2022.0.0 there is a bug where using a function of the form Function<Flux, Flux> means that in AWSLambdaUtils.isSupportedAWSType this returns false. This is because the Type passed into the method isSupportedAWSType(Type inputType) is Flux<T> rather than the generic type.

I.e. for the event type com.amazonaws.services.lambda.runtime.events.S3Event
String typeName = "reactor.core.publisher.Flux<com.amazonaws.services.lambda.runtime.events.SQSEvent>"

and therefore

 		return typeName.equals("com.amazonaws.services.lambda.runtime.events.APIGatewayV2HTTPEvent")
				|| typeName.equals("com.amazonaws.services.lambda.runtime.events.S3Event")
				|| typeName.equals("com.amazonaws.services.lambda.runtime.events.APIGatewayProxyRequestEvent")
				|| typeName.equals("com.amazonaws.services.lambda.runtime.events.SNSEvent")
				.....

returns false.

N.B A function without flux using com.amazonaws.services.lambda.runtime.events.S3Event works fine where AWSLambdaUtils.isSupportedAWSType returns true.

Sample
If you look at https://github.com/davidmelia/spring-cloud-function-zipkin/tree/bug I have the test CallFunctionInvoker which calls three types of functions

1. Calls a Flux<S3Event> function which results in a
   java.lang.ClassCastException: class [B cannot be cast to class com.amazonaws.services.lambda.runtime.events.S3Event ([B is in module java.base of loader 'bootstrap'; com.amazonaws.services.lambda.runtime.events.S3Event is in unnamed module of loader 'app')

because AWSLambdaUtils.isSupportedAWSType returns false so does not use AWS serialisation.

2. A standard S3Event function which works fine as is not wrapped in a flux and therefore AWSLambdaUtils.isSupportedAWSType returns true

3. An Flux<SQSEvent> function where AWSLambdaUtils.isSupportedAWSType returns false but still works by fluke as SQSEvent can be marshalled by jackson -

Hope this is enough detail.

Thanks

[olegz]

Sure, we can fix it, but given that non of these inputs are truly reactive you won't be able to utilise any of the reactor features (e..g, backpressure) and only use the API which IMHO will complicate things unnecessarily

[davidmelia]

I appreciate it's not reactive in this case however we have a mix of AWS cloud functions and webflux cloud functions so this gives me a consistent API paradigm + we can migrate one to another without much fuss + we have internal libs based on reactor which we share. I think this also helps consistency within spring cloud function which does say it supports Flux.

@olegz For these reasons could it be fixed? :-)

[davidmelia]

Is this OK @olegz ?

[olegz]

I will look at that, thanks