Description
The fix in #409 addressed the issue with Supplier/Function/Consumer beans ending up in the function registry in applications that were not meant to be functional.
There is another scenario: applications that do intend to be functional, and provide a proper Supplier/Function/Consumer bean, but also happen to declare (or pull in through dependencies) one or more accidentally functional beans. These would be identified as valid Supplier/Function/Consumer at the first stage. If only a single accidentally functional bean existed, it would get caught in the declared type validations. But if one real and one or more accidental functional beans exist, the logic never gets that far because it trips up a validation for the number of functional beans, which results in the function definition never being added to the function registry.
From a user application perspective, a warning message "Found more then one function beans in BeanFactory" is logged, and the binder is never activated. User applications would have to set spring.cloud.function.definition explicitly to get correct behavior.
One possible solution is to prevent "accidentally functional" beans from becoming candidates for autodiscovery. For example, this validation block of code could become a filter to be applied while aggregating functions, before the check for the number of autodiscovered functions is done.
For additional context, see spring-attic/spring-cloud-gcp#1997 and this sample application that works because it sets the spring.cloud.function.definition bean.