Simple function registry is not using conversion hint to de-serialize message to input type provided in the cloud function

[sudhu678]

Describe the bug
The simple function registry checks whether a conversion hint is required in order to invoke the respective message converter. For the below input type, conversion happens without type. By using the default JSON converter, the message is deserialized to LinkedHashMap instead of the Java class for Event which is a generic type and Account list type.

Consumer<org.springframework.messaging.Message<Message<Event<List<Account>>>>>

Why don't you consider actualType for conversion if it has valid input here?

Sample
If possible, please provide a test case or sample application that reproduces
the problem. This makes it much easier for us to diagnose the problem and to verify that
we have fixed it.

[olegz]

I am not sure what you are asking. - "If possible, please provide a test case or sample application that reproduces
the problem. This makes it much easier for us to diagnose the problem and to verify that
we have fixed it."

That is what we are typically asking developers to provide.

Regardless, I just verified that conversion hint is indeed working and we do have a test case for it - https://github.com/spring-cloud/spring-cloud-function/blob/main/spring-cloud-function-context/src/test/java/org/springframework/cloud/function/userissues/UserIssuesTests.java#L61C19-L61C19

[sudhu678]

Could you please confirm post-conversion data type is the actual Java class and not linkedhashmap? In my test, both event and list of accounts are returned as linkedhashmap instead of the respective java class. We had to convert the payload using the Jackson library to Java class.

[olegz]

Yes, i cam confirm as the test validates against the POJO

public Function<List<Product>, Integer> consumer() {
	return v -> {
		assertThat(v.get(0).getName()).isEqualTo("julien");
		assertThat(v.get(1).getName()).isEqualTo("ricky");
		assertThat(v.get(2).getName()).isEqualTo("bubbles");
		return v.size();
	};
}

[olegz]

Perhaps you can provide a small sample that reproduces the issue so we can tale a look. just create one and oush iyt to github somewhere

[sudhu678]

If you carefully observe my code input has Spring message class wrapped by our custom message (generic type) followed by Event and then List of units

Custom message class:

public class Message<T> {
   private T body;
}

Event Class:

public class Event<T>{
  private T payload;
}

Unit class

public class Unit {
   private name;
}

After consuming the message, we expect the message to be de-serialized to the below composite type

However, the event and list of units are de-serialized as a linked hashmap.

The body is deserialized as a linked hashmap instead of the event Java class

Similarly, units are de-serialized as linked hashmap instead of the unit Java class

springBootVersion=2.7.12

[olegz]

I'll take a look shortly, but seems like a bit of over-engineering here. .Spring Message as implementation of a pattern has everything you need. What are you gaining by adding additional hierarchy which also seems redundant?

[sudhu678]

All of our existing microservices use this format. We don't want to take a big undertaking now. If the below method returns true then conversion works fine using the actual type. If the actual type is a Spring generic message, the code won't use a full hierarchy of type conversion.