How to change field return type in middleware

[mvarendorff]

For a new requirement, I am trying to add an additional type as union to the existing results, i.e. if the code says that a mutation resolver returns FooPayload, I want the schema to say that resolver returns FooPayload | BarPayload. How would I best go about this?

I discovered FieldMiddlewareInterface and my initial instinct was to do something like akin to this

final readonly class ValidationResultFieldMiddleware implements FieldMiddlewareInterface
{
    public function __construct(
        private RecursiveTypeMapperInterface $typeMapper,
        private NamingStrategyInterface $namingStrategy,
    ) {}

    public function process(
        QueryFieldDescriptor $queryFieldDescriptor,
        FieldHandlerInterface $fieldHandler,
    ): ?FieldDefinition {
        $oldType = $queryFieldDescriptor->getType();
        $barPayloadType = $this->typeMapper->mapNameToType('BarPayload');

        $typeUnion = new UnionType([$oldType, $errorListType], $this->typeMapper, $this->namingStrategy);
        $newFieldDescriptor = $queryFieldDescriptor->withType($typeUnion);

        return $fieldHandler->handle($newFieldDescriptor);
    }
}

however this fails in our Symfony setup because no service of type RecursiveTypeMapperInterface is registered. I tried various combinations of TypeMappers but could not find any that were registered. I also tried my luck with TypeMapperFactory however that in turn requires me to have access to an instance of FactoryContext which I don't have either.

Am I on the completely wrong track here? Is this even possible or intended to be possible presently?

A little context as to what I am trying to achieve: We recently quite painfully learned that our current validation concept is not valid per the GraphQL Spec (long story...) and we now landed on wanting to return validation errors as part of the payload as a potential path forward. For that, I am to prototype how to centralize this process to avoid having validation logic explicitly present on each of several dozen mutation resolvers, this experiment being one of them.

[oojacoboo]

because no service of type RecursiveTypeMapperInterface is registered

Sounds like you need to fix your DI and register a RecursiveTypeMapperInterface service.

[mvarendorff]

Right, and this might be my bad for opening the issue here and not in the -bundle repo but is there any guidance on what might be available to build that up or access an instance? Every class I checked that might come in handy to build or access it is not in DI either and I was hoping on internal knowledge of the project if you might have any idea from where this instance might be accessible (think some centralized context for instance).

[oojacoboo]

Also, this sounds like a really bad idea. Validation errors should be thrown with exceptions and included in the error response object.

[mvarendorff]

100% on your side here, however the techlead considers validation errors as domain specific and thus would like them as part of the schema if possible. As mentioned in the issue, I am largely poking around to see what could work and what might now so it's not clear this is what will eventually happen.

[oojacoboo]

I mean, you can include whatever you want in the error array

https://graphqlite.thecodingmachine.io/docs/error-handling

I don't know what "domain specific" has to do with anything here. All validation is domain specific.

[mvarendorff]

"Domain specific" is his argument as to why it should be be in the largely untyped errors section of the response but fully typed in the data section. Again: I don't necessarily agree with that stance but I am freelancing in this project and the two leads would like me to explore technical solutions to make that a reality so that's what I am trying to do.

[oojacoboo]

You can expose an enum over the graph and reference the case in the error array. I'm out of suggestions for you. But you can have your "expert" "techlead" discuss this further if you like.