Multiply bugs in spring-cloud-function module related to avro schema regisration

[iozho]

Hi:

I would like to report 3 issues:

1. It appears that AvroSchemaMessageConverter module has been registered twice in ContextFunctionCatalogAutoConfiguration.functionCatalog:
   

2. There is a race condition which causes avro schema registration to fail on initial setup. This happens when a service start and when at least 2 request are made (hence 2 threads are spawn). When one thread sets output conversion to true and the other to false, registration fail since code that we pass to the apache kafka client is bytes[] instead of GenericContainer. Because of that we send wrong schema i.e. {"schema" : "bytes"}. Files FunctionAroundWrapper.java and AvroSchemaUtils.java .
   
   

3. It seems isSkipOutputConversion flag in FunctionInvocationWrapper and Function (functionToInvoke) has different values (own copy). It seems inconsistency issue and it is not clear which one is honored in the execution context.

Let me know if you need more info.

Thanks

[olegz]

@sobychacko can you please take a look at this?

[sobychacko]

@iozho Could you please create a very minimal sample application (that is standalone) in which we can reproduce these issues that you are running into? That way, we can triage them better.

[iozho]

Hi @sobychacko ,

Sorry for the delayed response. I have created a dummy app which reproduce the issues (primary number 2) and attached in this thread. Please let me know if I could help further.

dummy-avro-app.zip

[iozho]

Hi guys,

Any updates?

[sobychacko]

@iozho My apologies for not getting back to this issue. I am finally able to look at this issue now, but want to mention an important detail. We removed the AVRO converter and the related code from Spring Cloud Function and migrated them to Spring Cloud Stream under schema-registry in the 4.0.x branch. However, we have not removed them from 3.2.x branch and therefore you might still run into this issue. I think you are running into the issue because of a clash with the Confluent AVRO converter. If that is the case, we can remove this converter getting configured in the 3.2.x branch.

[sobychacko]

@iozho We removed the loading of the AVRO converter bean in 3.2.x.. Could you please check if that addresses your issues?

[iozho]

Sure. It should be easy with the test app I have created for you. I will try it out with different applications as well (it might take time before I will get back to you).

[iozho]

@sobychacko Unfortunately the fix did not work as it is but if I set “spring.cloud.stream.avro.enabled” to false, I cannot reproduce the issue anymore. I think you need to change “matchIfMissing = true” to “matchIfMissing = false” which will exclude the AVRO converter by default. Please let me know when you have the change in 3.2.x branch and I will be happy to try it out.

Thank you for your help on this issue.

[sobychacko]

@iozho Sorry once again for the delay in responding. The fact that we set matchIfMissing to true is by design. Since yours is an edge case, we want you to opt out of the converter by deliberately setting the property (spring.cloud.stream.avro.enabled) to false. In that way, any existing 3.2.x users who rely on this converter will continue to use it without any code change since the property is matched as true when not provided. Since you don't want this converter, you can set the property to false and thus not activate it. Does that make sense?

[iozho]

Make sense. Thank you again for the support on this issue.

[sobychacko]

@iozho Thank you for your quick response. We will go ahead and close this issue. Feel free to re-open if there is a need or any issues.