Hello, before reading my comments, you should look at the fixed ticket for more context.

So, given the following classes (taken from the example) :

interface PriceInterface {}interface VariantPriceInterfaceextends PriceInterface {}abstractclass AbstractPriceimplements PriceInterface {}class VariantSamplePriceextends AbstractPriceimplements VariantPriceInterface {}

and validation file :

PriceInterface:getters:value:            -NotBlank:~

To begin, I tried to improve the work done by@lemoinem to fix the previous issue of double validation I reported (cf#19943). I tried to make it work with the new case I have found but I couldn't. IMO, it is impossible without changing some public methods signatures. I will describe the problem with the example classes.

The problem is that both classAbstractPrice and interfaceVariantPriceInterface implements thePriceInterface interface but when you get their metadata, you get them independently. I mean there is no "context" that indicates that in reality, we want the metadata for theVariantSamplePrice model. In other words, both classes don't know about each other, they cannot know that they both implement the same interface, and have no way of knowing if the constraints for thePriceInterface have already been added or no.

So I had a different approach, and thought that I could "clean" the duplicated constraints after they were all added. There are several ways to do this, I chose to make the check as soon as possible, when the constraints are merged, so the metadata are in an "invalid" state the shortest time. The check is simple : don't mergeMemberMetadata constraints if there are already defined for the same property and the same class.

To illustrate with my example : at a given time, theVariantSamplePrice metadata will already have aGetterMetadata for the propertyvalue of the classPriceInterface either coming from theAbstractPrice or theVariantPriceInterface metadata. Then, thePriceInterface metadata will be merged a second time in theVariantSamplePrice metadata (coming from the other class metadata). But with the check, the constraints won't be merged another time. Because aMemberMetadata for the same property and of the same class exists so it means that the exact same constraints have already been added.

My main concern is the choice of whichMemberMetadata should be kept as there are not exactly the same : depending of of its class, the groups in the constraints are not the same. I honestly don't know if this is a problem or not.

Also, I originally deleted@lemoinem work because it was not really needed anymore and it covers less cases. But actually, as long as there are only interfaces concerned, it works better because the metadata are never "invalid". But I don't know if it's logical to keep both checks in different files, I need advice on this.