Cannot return null for non-nullable field

[omahili]

Let's say we have a subgraph that looks like this:

type Query {
   foo: Foo!
}

and when we send the following query to the gateway:

query {
   foo1: foo
   foo2: foo
}

Now let's say the aliased query foo1 fails with an error, the subgraph will respond with something like:

{
 "errors": [
    {
      "message": "Lorem ipsum.",
      "locations": [...],
      "path": ["_v0_foo"],
      "extensions": [...]
    }
  ],
  "data": null
}

We'd expect this response to be correctly returned from the gateway, however the graphql validation fails and the gateway throws this error:

Cannot return null for non-nullable field Query.foo.

We understand that due to the fact that foo is non nullable field partial responses are not allowed in this case, however since the root object data is returned as null we'd expect the response to be correctly returned in this case.

We're using hive as nestjs module:

@graphql-hive/nestjs: 1.0.15
graphql: 16.11.0

Are we missing something or is this actually a bug?

[ardatan]

This is expected per GraphQL spec. If one of the non-nullable fields are null, the entire object will be null with an error.

[omahili]

Yes right, but in this case the gateway throws Cannot return null for non-nullable field Query.foo. even though the subgraph is correctly returning null for the entire object.

[ardatan]

It is because the gateway sends a request for each root field seperately to build the root object by collecting fields from the subgraphs. It asks for foo from the subgraph then when it returns null, it treats foo is null. In order to tell you more, we need to see a reproduction on CodeSandbox or StackBlitz.

[omahili]

In this case aren't the two queries batched since part of the same subgraph? Sure, I can put together a repro.

[omahili]

@ardatan I created a reproduction repo here starting from the federation example and added some details to the readme.

[omahili]

Following back on this, is there an update?

[ardatan]

Currently the gateway implementation handles root fields individually.
It starts with review0 and creates a query for review0 asking for review(author: "1") then it continues with review1 asking for review(author: "3"). Then those two are batched in a same query because they exist in the same subgraph. Then the batched query fails because review is non-nullable and a non-nullable field causes the entire query to fail. And you get the review0's error which is also failed.
This is an issue with the mapping in the batch execution. No updates on our end for now.
Any PRs and more contributions are welcome in the meanwhile. Thanks for the reproduction.

[omahili]

Thanks for the overview, it does help. Yes sure, while debugging the issue I also stumbled across another issue, with dataloader this time, when two operations error out e.g.:

{
  review3: review(author: "3") {
    id
  }
  review4: review(author: "4") {
    id
  }
}

Same json response and the stack trace looks like:

TypeError: DataLoader must be constructed with a function which accepts Array<key> and returns Promise<Array<value>>, but the function did not return a Promise of an Array: [object Object],.
    at /.../hive-repro/node_modules/dataloader/index.js:302:13
    at process.processTicksAndRejections (node:internal/process/task_queues:95:5) {
  path: [ 'review3' ],
  locations: [ { line: 1, column: 2 } ],
  extensions: [Object: null prototype] {}
}

I can update the repro repository to include these details as well. If you prefer I can create a new issue for it.