I haven't gone through all the cases, but if you look at the actual queries it makes sense, e.g. case 2.1:

SELECT t0.name AS name_1, t0.id AS id_2, t0.parent_id AS parent_id_3, t0.root_id AS root_id_4
FROM foo t0 WHERE t0.root_id = 1 AND t0.parent_id = 2 LIMIT 1

The EntityValueResovler doesn't "inject the first child", instead it tries to load an entity by criteria. Since your Foo entity has both a property named root and one named parent, it loads by that criteria. This is not a bug, but expected behavior that can be disabled with the following configuration:

doctrine:
    orm:
        controller_resolver:
            # Set to false to disable using route placeholders as lookup criteria when the primary key
            # doesn't match the argument name
            auto_mapping: false

If you look at the actual queries, it makes sense

I have looked and agree there is nothing wrong with the query itself. I'm complaining that my entity is populated with data I didn't want when I didn't ask for it.

The EntityValueResovler doesn't "inject the first child", instead it tries to load an entity by criteria

I agree my description was inaccurate, but the end effect is the same: it populates the first entity in the relation.

With all of the above said, setting doctrine.orm.controller_resolver.auto_mapping: false indeed addresses the behaviour I described as buggy. Thank you for that; I was unaware of that option.

I'm curious, how does one find this in the docs? Searching for auto_mapping finds things related to orm.doctrine.auto_mapping but not doctrine.orm.controller_resolver.auto_mapping. I found it in bin/console config:dump-reference DoctrineBundle, but I am also guilty of not looking at the dumped reference very often. It's definitely not the first place I look at to learn new things

I still think the core issue remains, because with the default auto_mapping: false, the behaviour of EntityValueResolver is inconsistent, relying on whether or not the controller argument name appears in the parameters or query part of the request. See cases 2 and 3 and the differences in the behaviour:

I would expect the $child to be populated in both cases according to the auto_mapping setting if that one is meant to drive the business logic.

I'm curious, how does one find this in the docs?

Good question, not sure what the answer is. The option is mentioned here, but I knew about it from the original PR, so I can't judge how easy it is to find out about it without having some prior knowledge.

I still think the core issue remains, because with the default auto_mapping: false, the behaviour of EntityValueResolver is inconsistent, relying on whether or not the controller argument name appears in the parameters or query part of the request. See cases 2 and 3 and the differences in the behaviour:
I would expect the $child to be populated in both cases according to the auto_mapping setting if that one is meant to drive the business logic.

Honestly, I'm having trouble understanding this part, so I can't really comment 😄 . What inconsistencies are you referring to?

Honestly, I'm having trouble understanding this part,

No wonder. I meant to ask you to have a look at cases 4 and 5. Let's blame the early morning and lack of coffee on my end. Let me take you through the key points:

Case 4:

#[Route('/case4/{root?null}/{parent?}', name: 'case4')]
public function case4(?Foo $root = null, ?Foo $parent = null, ?Foo $child = null): Response {

Calling https://127.0.0.1:8002/case4/1/2, the $child is populated even though I didn't ask for it.

The entity resolver finds a result when searching for ['root' => 1, 'parent' => 2] and injects the result into the $child no matter what.

Case 5:

#[Route('/case5/{root?null}/{parent?null}/{child?}', name: 'case5')]
public function case5(?Foo $root = null, ?Foo $parent = null, ?Foo $child = null): Response {

Calling https://127.0.0.1:8002/case5/1/2, the $child is null as expected.

There is a bit of a twist there too. The child entity relates to both root and parent. Currently, when the child ID is not provided, EntityValueResovler probably uses both root and parent values to find the child entity.

So what if the parent entity didn't relate to the provided root ID?

That's why I generated two sets of root-parent-child fixtures. Going back to "Case 4", if you provide a root and parent that are unrelated, the child is not loaded. Just open https://127.0.0.1:8002/case4/1/5 of my reproducer.

This is a correct result of the current behaviour because both root and parent IDs are used to look up a child, but no child belongs to root 1 and parent 2. Hence I'm claiming the current behaviour is not right.

So there you have it. Case 4 populates $child (or not) based on the other request parameters; that's a problem, the way I see it: a match of a relation name and a route parameter can't be reliably used to conclude that the parameter carries an ID found on the other side of the relation.

Calling https://127.0.0.1:8002/case4/1/2, the $child is populated even though I didn't ask for it.

That's odd, I'm getting null with auto_mapping: false.

That's odd, I'm getting null with auto_mapping: false.

Yes, but not with auto_mapping: true, which is the default setting, so in use by a ton of projects.

I think I need to gather my thoughts to re-phrase what's the problem here. I hear your point with the auto_mapping. The config comment says clearly, # Set to false to disable using route placeholders as lookup criteria when the primary key doesn't match the argument name, which correctly describes what's happening, but I still think the idea behind it has some flaws.

If nothing else, the docs might need an upgrade.

I'll come back in a few days to either explain my beef or close this.

Thanks for taking time to discuss this topic.

This issue is the reason why I'm advocating since years to kill this auto_mapping feature. At least, when implement the argument resolver, I managed to make it possible to disable that feature globally in the config. In the DoctrineParamConverter of SensioFrameworkExtraBundle, there was no such option.

Hey, thanks for your report!
There has not been a lot of activity here for a while. Is this bug still relevant? Have you managed to find a workaround?

Could I get an answer? If I do not hear anything I will assume this issue is resolved or abandoned. Please get back to me <3

Hey,

I didn't hear anything so I'm going to close it. Feel free to comment if this is still relevant, I can always reopen!

Please check #54455 for a possible solution to these ambiguities. Can you make your code behave more predictably with this PR @janklan?

I played with the reproducer and I confirm all cases are fixed by #54455, provided we set framework.controller_resolver.auto_mapping to false

@nicolas-grekas Great news, sorry for the no-answer; I was planning to check it out over the weekend. Do you still need me to see what's up? If you're happy, I'm happy.

Found this issue while trying to resolve the deprecation message. Shouldn't this have a recipe? Or does it truly deserve manual configuration?? Symfony 6.4.6 here. Can't upgrade to 7 yet.