Consider allowing passthrough execution to resolver/mutation even if validator fails

[oising]

Use case: Sometimes you may want to treat the validation as a partial failure, and allow the mutation/resolver to execute anyway, so a payload can be returned. Might I suggest using an extension method on IResolverContext to allow the method to see the result(s) for each input type, and make its own decisions on how to proceed.

There is a related issue with Strawberry Shake - if the payload for the mutation is non-nullable, fairybread will cause a null to flow through and causes a null ref exception in the deserializer, if validation fails.

I don't mind doing the work, but just wanted your advice on this. Returning an error/errors and a payload doesn't seem to be against the graphql spec.

[benmccallum]

I think it's worth potentially making the error result handler (which typically just adds the errors to the response with context.ReportError) actually return a bool for whether next should be called or not.

That way someone can fully swap our the handler of errors to do what they want, e.g. still let some of it through or whatever.

It might not handle what you were talking about in slack, but I think it's a valid use case for everyone.

Would be a breaking change, so will schedule in next milestone unless it's useful earlier.

[oising]

That sounds useful, @benmccallum -- I gave up on trying to modify the behaviour to fit my needs, but we're still using fairybread. Mutations with an array of inputs will fail the entire batch if one is bad, but that's easy to manage on the client with a resubmit of the entire batch.

[oising]

Did you figure out an approach to use?

[benmccallum]

@oising , I think I had a plan in my last comment above; which was more about making the handling a bit more flexible if you wanted it to not abort entirely. Just haven't had time to go and make the change :P