What if there's a "field error" during serial execution?

[rmosolgo]

Let's say you have a mutation type like:

type Mutation {
  push(val: Int!): Int!
}

And you send a query like:

mutation {
  one: push(val: 1)
  thirteen: push(val: 13)
  two: push(val: 2)
}

And, given the unluckiness of 13, push(val: 13) causes an internal error, resulting a null value for that field. What should happen? Specifically:

• Should the result be { data: null, errors: [ /* 1 error */] }? (Judging by "Errors and Non-Nullability", yes.)
• Should push(val: 2) be executed? (I can't quite figure it out from "Normal and Serial Execution".)

[stubailo]

I think not executing push(val: 2) would be a really valuable property - that would make it meaningful to include multiple mutations in one document, rather than sending a bunch of separate mutations.

[stubailo]

On the other hand, if #252 (nested serial fields) was introduced, you could specify dependencies via:

mutation {
  one: push(val: 1) {
    then { # proxy for Mutation
      thirteen: push(val: 13)
    }
  }
  two: push(val: 2)
}

Actually; the above might already be spec compliant. HMMM!!!

[OlegIlyenko]

I also always had an assumption that push(val: 2) should not be executed because of the error handling rules. Now that you pointed this out, it is indeed unclear how this should be handled according to the spec.

I would agree with @stubailo on this one. It is quite valuable property to have. If you would like to give user a choice, you can provide two mutation field variations: nullable and not-null.

[rmosolgo]

Thanks for shedding some light on this one! I've merged that behavior into GraphQL Ruby. Do you think it should be clarified in the spec, or is the spec sufficient already?

[OlegIlyenko]

yes, I think it needs to be explicitly stated un the spec. From what I can tell, It's not clear how execution should behave in this situation.

Even if this behavior can be inferred from other parts of the spec, I think it would be beneficial if this aspect is explicitly described.

[leebyron]

Should the result be { data: null, errors: [ /* 1 error */] }? (Judging by "Errors and Non-Nullability", yes.)

This is the most important question, since the result is what's observable to the request, and this is absolutely correct.

Should push(val: 2) be executed?

This has been intentionally ambiguous since the requestor cannot observe the results, however I think it's totally acceptable to not execute it in the face of errors. I've added some additional text in #438 which specifically points out that execution of sibling fields may be cancelled in the case that an error occurs on a non-null field.