MutationResolverInterface no longer working properly in v3.3 about core

[soyuka]

thanks for the detailed report, there's nothing that said that resolvers should happen before validation but I think it's a valid behavior, I added a new test for that.

[NicoHaase]

The fix for this has been reverted, thus the bug has appeared again

[soyuka]

Back to this, we need to find a solution, I think it's confusing that we validate the data that gets resolved as validation should occur on the user input.
What I think would work is to disable validation (validate: false) and do the validation inside the resolver, would that work?

[NicoHaase]

What I've found in the meantime (maybe this is obvious to me, but it wasn't for me): setting event_listeners_backward_compatibility_layer: true helps to overcome this problem. But this is not a longtime solution, as this compatibility layer is removed within the next versions....

---

Still, validating the entity before it is completely populated looks strange to me. By simply thinking about the semantics of that, I can't see how this is right? I know that @codedge reported this as a new problem in #6370, but I would like to know more about their use case

[soyuka]

Isn't the resolver supposedly have the same behavior as a provider? Anyways, I'm considering adding an option to validate after the resolver is being called, this would work for both cases.

[NicoHaase]

Isn't the resolver supposedly have the same behavior as a provider?

I'm sorry, but I don't get the question. This feature has worked for some versions, and I thought I was on the save side when implementing it just as described at https://api-platform.com/docs/core/graphql/#custom-mutations, so I'm a bit confused about why this has changed when updating from 3.2 to 3.3

[codedge]

What I've found in the meantime (maybe this is obvious to me, but it wasn't for me): setting event_listeners_backward_compatibility_layer: true helps to overcome this problem. But this is not a longtime solution, as this compatibility layer is removed within the next versions....

Still, validating the entity before it is completely populated looks strange to me. By simply thinking about the semantics of that, I can't see how this is right? I know that @codedge reported this as a new problem in #6370, but I would like to know more about their use case

We do not validate the entity before, but the input data.

Example:
We expect the input of an amount passed to a mutation. The amount should be between two number, in a certain range. Why should we hit the custom logic in our custom resolver, if already the input is wrong? With using a custom DTO for the input, that has validation rules attached to the amount field, we make sure to get a correct input for further processing.

Even with 3.3.5 and these settings (no entry for event_listeners_backward_compatibility_layer)

api_platform:
  keep_legacy_inflector: false
  use_symfony_listeners: true

the validation does not run before reaching the resolver. We currently pin api-platform/core to 3.3.2, which works for us.

[durimjusaj]

Same issue here, MutationResolverInterface called after validation. We used MutationResolvers for the same reason @NicoHaase uses, to populate fields before validation, like user or default status which is relation, we have cases that we need to check data and populate a fields before validation. In RestApi I did all this with PRE_VALIDATE event subscribers, in graphql there is no events, before I used WriteStage to implement PRE_VALIDATE but since api_platform.graphql.resolver.stage.write service has been moved to legacy, also that is not possible anymore.

Implementing PRE_VALIDATE and POST_VALIDATE, would be a better solution for this and keep resolvers after validation.

[soyuka]

Can you check my PR? It adds an validateAfterResolver: true

[NicoHaase]

Yes, this part is working properly. Thanks for your help! I'll post an additional report, as I'm still facing a problem with security