[Form] EntityType: 'query_builder' and 'setMaxResults' weird behavior

[Adrien-H]

Symfony version(s) affected: 4.2.7

Description
I'm not sure this is a bug. It might be a simple question, but surely about a behavior I consider like weird.
In some Form, in some EntityType with 'multiple' => true, if you interfer with the query_builder and call setMaxResults(x) on the builder, then x will also enter in validation flow: the form field will be invalid if the number of submitted entities is greater than x.

How to reproduce
Let's consider this:

public function buildForm(FormBuilderInterface $builder, array $options): void
{
    $builder
        ->add('authors', EntityType::class, [
            'required' => false,
            'class' => User::class,
            'query_builder' => function (EntityRepository $r) {

            return $r
                ->createQueryBuilder('user')
                ->setMaxResults(2)
            ;
        },
   ;
}

From this point, nothing stops the frontend from sending more than 2 entities. You could imagine Select2 field with its own AJAX request. And this will lead to the form being invalid.

One could argue this makes no sense to limit the query to 2 results then sending 3 entities. While I could agree with this, my concern is not about the logic behind the behavior, but the fact that I think it's not the role of the query_builder option to define parallel constraints on its way or have any influence upon form validation. It is not documented, it raises very generic error messages, in one word it is rather unpredictable.

Possible Solution
If it's a bug, well it's a bug, happy for having reported it. I did not have any time to dig into the code and understand the behavior, though, so I did not come out with a fix. I could try finding some time for this if you ask. (:

If it's a wanted behavior, I won't debate the choice itself, but I think it could be better documented or at least raise a more accurate error message on the form field.

[xabbuh]

The EntityType extends the ChoiceType. Its semantic is that your provide a list of choices to the user from which the user chooses one or multiple. Every submitted value that is not part of this choice list of treated being invalid. This is the expected behaviour of the ChoiceType and thus the expected behaviour of all its concrete subtypes too. So I am going to close here as there is no bug. Thank you for understanding.

[Adrien-H]

The issue I faced was just concerning the LIMIT. If I setMaxResults(3), still can I select values that are not in the original result. I just cannot select more than 3 values.

While I understand the semantic you describe of "You queryied a b c, so pick what you want of a b c", this is not the behavior I am observing. It's more like "Your queryied a b c, so pick whatever you want but no more than 3."

But I respect your point, this is revealed anyway by a bad usage of EntityType. Thank you for your answer, have a good day. (:

[xabbuh]

Sorry, I did not understand your description that way as your example was talking about a limit of two but a submission of three values. This looks like a bug to me then.

[Adrien-H]

Okay, yeah, sorry, I probably lacked precision in my first post. I was not aware of the ChoiceType behavior you described.

I will try to find time this week to investigate.

[HeahDude]

Thank you @Adrien-H for reporting this issue, I was able to work on a fix and opened #34900.

The problem is that we try to optimize the query on submission by adding a WHERE ... IN (...) clause to the builder define in the option, which is used before the limit clause to fetch the results.

This is an edge case where we should not try to optimize the loading since we cannot fix it on the db layer, and given that is about a "limit" clause this should not be a big deal hopefully.