Just to be clear, my solution returns errors as errors to the client, not as data. It is returning errors as part of the Elixir resolver return value sure, but then it’s converted to a GraphQL error here:

  field :entity, :entity, resolve fn
    %{entity: entity}, _, _ -> {:ok, entity}
    %{error: error}, _, _ -> error
  end

Notice how in the mutation resolver result item at index 1 is %{error: {:error, "reason"}} and so the value is unpacked from the %{error: key it means that the resolver is returning {:error, "reason"} which means you get a proper GraphQL error.

That is the question, and they definitely are not, nor is “coercion” or “preparation” the same as resolution or execution. If you read through the “Executing fields” section GraphQL I think it’s pretty clear that a given item in a list cannot also be a field. It doesn’t take arguments, it doesn’t have a distinct selection set, etc.

The other thing to emphasize is that we’re talking about the resolution of a specific mutation field. That field has a single return value. That value can be a list type, but that list type is not then N resolutions, where there is a distinct resolution for each item in the list. Rather there is one resolution (the resolution of the mutation field) that returns one value (a list), there is a “result coercion” of that value, which involves a result coercion of each item in the list. Then fields in the selection set on the result are executed on each result. There is no field that represents individual item from parent list -> individual item | null | errors, nor is there a resolver for such.