After one root mutation field errors, do the later root mutation fields still run?

## The question behind the question Interviewers ask this to find out whether you have read the execution algorithm or only absorbed the folklore. The folklore says "mutations run serially, one after another", and people quietly extend that into "so the server stops when one fails". The serial rule is an **ordering** guarantee. It says nothing about stopping. ## What the algorithm actually does Executing a mutation's root selection set is a loop: take the next field in document order, resolve it, complete its value, append any error that was raised, take the next field. The loop has no condition that consults the accumulated error list. Nothing in it says "if errors is non-empty, skip the remainder". A conforming executor therefore runs every root field the client wrote, whatever happened to the ones before. A **field error** — a resolver raising rather than returning — is deliberately local. It is recorded and the field is completed as `null`. Execution of the rest of the request goes on. ## What that costs you in a mutation For a query this is barely interesting: one branch of a read comes back empty. For a mutation it is a real hazard, because "continue" means "perform the next write". Take a restaurant ordering graph closing out a table: ```graphql mutation CloseOutTable { applyDiscount(orderId: "ord_48213", code: "STAFF15") { totalCents } voidLine(orderLineId: "line_9127") { orderId } capturePayment(orderId: "ord_48213", amountCents: 4183) { receiptId } } ``` `voidLine` fails on a permission check that only runs once the resolver has loaded the line — too late to prevent anything. The executor nulls that field, notes the error, and then runs `capturePayment`, which charges 4,183 cents for an order that still contains the line the server just refused to remove. The guest is charged for food they sent back, and the response reporting it looks like a healthy partial result. ## The ordering heuristic that does not save you A common instinct is to sort root fields "riskiest first, most damaging last", on the theory that the dangerous write will never be reached. It does not work, because the executor does not skip. Ordering only decides *which* writes have already committed by the time something fails; it never prevents a later one. The only construct that reliably keeps the capture from happening is a single field whose resolver decides, in code, not to capture. ## Non-Null changes the view, not the history If the failing root field is declared Non-Null, the `null` it produced cannot stay there, so the null propagates up to the nearest nullable position — for a root field, that is `data` itself, which becomes `null`. The client then sees no payloads at all. It is worth being very clear about what that does and does not mean: it changes **what the client can read**, and it does not change **what the server did**. All three writes still ran. The discount is applied and the payment is captured; the client just cannot see the receipt id, which makes the situation strictly harder to recover from, not easier. ## There is no abort switch Candidates sometimes reach for one of these, and none of them exists: * an executable directive that aborts the operation on error — no such directive is specified, and inventing a name for one is a bad sign; * an operation-level flag or argument that makes the document all-or-nothing; * declaring the fields Non-Null so that "the rest is skipped" — as above, that is a response-shaping rule, applied during value completion, not an execution guard; * splitting the writes into several operations in one document — a request executes exactly one operation, so the others simply never run. ## What you do instead You express the sequencing where sequencing decisions can actually be made: inside one resolver. ```pseudocode resolve closeOutTable(input): begin transaction line = load(input.orderLineId) if not caller.mayVoid(line): # check FIRST, before any write rollback; return failure("VOID_NOT_PERMITTED") applyDiscount(input.orderId, input.code) voidLine(line) capturePayment(input.orderId, recomputeTotal(input.orderId)) commit ``` Two things changed, and both matter. The authorization decision moved ahead of the first write, so the request that cannot succeed never starts. And the three writes became one unit that a single piece of code controls, so "stop before capturing" is now expressible — it is an `if` statement, which is exactly the sort of thing an execution algorithm was never going to give you.