With spring-data-dynamodb:4.2.3 using spring-data-commons:1.11.4-RELEASE, the fooRepo.save(…) call in FooService would call the save(…) method on FooRepositoryCustom. with spring-data-dynamodb:4.5.0 and spring-data-commons:1.13.1-RELEASE, it actually calls SimpleDynamoDBCrudRepository.save(…), which is the base implementation used by the Spring scoped proxy.
After some quality time in side-by-side debuggers with my code running on the new and old versions of the library, I've tracked the offending code change down to this commit as well as a few other changes within DefaultRepositoryInformation and specifically, the parametersMatch(…) method. The logic over whether a custom repository method "matches" seems to have changed in a very odd and restrictive way.
What I can't figure out is why exactly Spring cannot tell that a method with the exact needed signature in my custom repository is not suitable to call vs. the proxy method in the spring-data-dynamodb library.
causes the correct method to be invoked, but this should not be necessary; it is also tedious to do for every repository that happens to have a custom implementation of a "standard" CrudRepository method.
Methods in custom repositories should be respected by return and parameter value
Thanks for the detailed analysis, Ryon. In fact, the refactoring seems to have lost the consideration of exact matches on the declared method. I have a local fix ready with that additional if clause introduced again.
In the mean time, it should be sufficient to introduce the method on the implementation class with the exact generic signature (<T extends Foo> T save(T entity)), i.e. you don't need to pull it up into the interface necessarily