🦋 Changeset detected

Latest commit: 80683d9

The changes in this PR will be included in the next version bump.

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

@yaacovCR – I'm also very curious about the lines I have commented out here: https://github.com/ardatan/graphql-tools/pull/2288/files#diff-b5b7aa7f61f68d5eb95eec0f2a889d9afe4cf5d043547167ee3cee7bb127ea56R138-R143

That enables a single-record query, which appears to have higher fidelity merge results than the array-batched counterpart. For example, using args with the thing field gives this:

{
  "errors": [
    {
      "message": "nope",
      "locations": [],
      "path": [
        "parent",
        "thing",
        "name"
      ]
    },
    {
      "message": "nope",
      "locations": [],
      "path": [
        "parent",
        "thing",
        "desc"
      ]
    }
  ],
  "data": {
    "parent": {
      "thing": {
        "name": null,
        "desc": null,
        "id": "23"
      }
    }
  }
}

While using argsFromKeys with the things field gives this:

{
  "errors": [
    {
      "message": "nope",
      "locations": [],
      "path": [
        "parent",
        "thing"
      ]
    }
  ],
  "data": {
    "parent": {
      "thing": null
    }
  }
}

Technically I'd expect single-record versus array-batched to produce analogous results. The single-record merge actually returned partial data (the local ID), and then gave two field errors, while the array-batched merge failed resolving the entire object.

The single-record result is slightly more granular and therefor preferable from the results standpoint, but is less efficient to process than array batching. Is there a simple way that the more efficient array-batched version could match the granularity of the single-record result? If not, it’s not a big deal. I’ll take the efficiency of array batching over the granularity of a failed record, to which half a record is generally about as useful as no record at all.

Ack, you are completely right about this!

The "right" solution is to either traverse the result tree on every batchDelegateToSchema call and adjust every embedded error OR to somehow alert the CheckResult... transform that when it embeds the errors into the object by full path, it should transform the errors first.... But this should only happen when using batchDelegateToSchema and we know that the array result is actually not being returned as an array.... When delegating from list to list, error positions within the list need to be saved....

We have the ability to alter the default transforms passed to delegateToSchema using the delegation bindings argument...

But rather than changing all of that, keeping two setsb of bindings in sync, we should try to think of a simpler option