I understand the guidance for nullable fields due to error propagation (e.g. see #719) but wondering what the spec defines (or maybe should define) when propagation does occur. With a mutation operation such as: ``` mutation {m1 m2 m3} ``` then assume `m2` had an error and was non-nullable, the response should be: ``` { "data": null "errors": [{"path":["m2"], "message": "some error"}] } ``` The question is, should `m3` be executed? Maybe a strict reading of the spec would indicate `m3` must be executed, and the only way the client can know that it succeeded, is that there is no error for `m3`. So `m1` and `m3` were executed, both without errors, but the client has no ability to determine their values. For query operations, I would assume there is more freedom for the implementing engine, as operations are defined to be idempotent. So a similar: ``` query {q1 {q1a} q2 q3 {q3a} } ``` could avoid executing `q1a`, `q3a` if (non-nullable) `q2` failed, as any values it provides will not be returned. [obviously this is subject to timing based upon parallel execution, but can the engine avoid executing fields whose values can no longer be returned]. Maybe, it's all left as an choice for the implementing engine, and in the case of mutation, the response could be: ``` { "data": null "errors": [ {"path":["m2"], "message": "some error"} {"path":["m3"], "message": "canceled"} ] } ``` Wondering if there had been any discussion along these lines?