Random behavior in DelegatingByTypeSerializer based on type of delegates map

[MaheshAravindV]

In what version(s) of Spring for Apache Kafka are you seeing this issue?

3.3.6

Describe the bug

When creating a DelegatingByTypeSerializer with assignable = true, if one of the types in the input map is a child of another type, the serializer that gets picked is random.

To Reproduce

1. Create a DelegatingByTypeSerializer with assignable = true
2. Have one type in the input map as the child of another type
3. When a message of the child type is send, the actual serializer used is random if the map used to create the serializer does not enforce order. This is because the contract does not enforce people to use a SequencedMap.

Expected behavior

The order in which the serializer is picked for a type if there are multiple available should be deterministic.

Sample

https://github.com/MaheshAravindV/spring-kafka-delegating-serializer-sample

[artembilan]

I see.
Even if the logic there is like this:

private final Map<Class<?>, Serializer<?>> delegates = new LinkedHashMap<>();
...
this.delegates.putAll(delegates);

the provided map is copied to the internal LinkedHashMap and access order has to be deterministic, but between application restarts, the one run would have entries in one order, but another may have in different run.

I wonder if we can come up with some sorting algorithm internally instead of enforcing contract which still could fail if you do:

Map<Class<?>, Serializer<?>> typeMap = new LinkedHashMap<>();
typeMap.put(Object.class, new JsonSerializer<>());
typeMap.put(byte[].class, new ByteArraySerializer());

I mean this deterministic, but wrong by definition, since everything is going to be processed by the first entry.

[MaheshAravindV]

I was thinking it might be a simpler fix to have the onus on the person creating the Serializer to define the order since this seems to be a pretty niche use case. But the suggested approach should work as well.

[MaheshAravindV]

Either way, I can raise a PR for the same once we decide the approach.

[artembilan]

I prefer to have a sort algorithm inside of this DelegatingByTypeSerializer with JavaDoc explanation what is going on when we use assignable = true.

[MaheshAravindV]

I am done with the changes but I am unable to open the contributor's agreement page.

[artembilan]

I think you talk about this page: https://github.com/spring-projects/spring-kafka?tab=readme-ov-file#contributing-to-spring-kafka.

Yes, that one has to be fixed. Thanks.
We follow now a DCO process: https://github.com/spring-projects/spring-kafka/blob/main/CONTRIBUTING.adoc#developer-certificate-of-origin

[MaheshAravindV]

Have raised a PR

[MaheshAravindV]

Hey, any update on this?