Data is getting set null when errors come from stitched remote schemas

[guifeliper]

Setup:

We have the following code for stitching the remote schemas; they are perfectly working.

const makeGatewaySchema = async () => {
  return stitchSchemas({
      subschemas: [
        {
          schema: await introspectSchema(remoteExecutorA, baseContext),
          executor: remoteExecutorA,
        },
        {
          schema: await introspectSchema(remoteExecutorB, baseContext),
          executor: remoteExecutorB,
        },
      ],
    }):
 }


const runServer = async () => {
  const schema = await makeGatewaySchema();
  const app = express();
  app.use(
    '/',
    graphqlHTTP(() => ({
      schema,
      graphiql: true,
    }))
  );

  let { PORT } = process.env;
  PORT = PORT || '3333';
  app.listen(PORT, () => {
    console.log(`Listening on http://localhost:${PORT}`);
  });
};

https://www.graphql-tools.com/docs/remote-schemas

Scenario 1:

The query has error and data, the data on the client-side is returned as null, and the error has its message aggregated. However, a simple console.log on remote executor shows us that we have data and more than one error coming from the underlying subschema. Here is the current response on the client-side:

{
   "errors":[
      {
         "message":"Account <###@###.com> not found, \nAccount <###@###.com> not found",
         "path":[
            "organization"
         ]
      }
   ],
   "data":{
      "organization":null
   }
}

The following response shows us what we receive from the remote executor.

{
   "errors":[
      {
         "message":"Account <###@###.com> not found",
         "path":[
            "Array"
         ],
         "extensions":[
            "Object"
         ]
      },
      {
         "message":"Account <###@###.com>  not found",
         "path":[
            "Array"
         ],
         "extensions":[
            "Object"
         ]
      }
   ],
   "data":{
      "__typename":"Query",
      "organization":{
         "accounts":[
            "Array"
         ],
         "__typename":"Organization"
      }
   }
}

Scenario 2:

The query has errors and no data. The response on the client-side receives a 500 network error. The following response shows us what we receive from the remote executor.

{
   "errors":[
      {
         "message":"Account <###@###.com> not found",
         "path":[
            "Array"
         ],
         "extensions":[
            "Object"
         ]
      },
      {
         "message":"Account <###@###.com>  not found",
         "path":[
            "Array"
         ],
         "extensions":[
            "Object"
         ]
      }
   ],
   "data": null
   }
}

Expectations

The data and error should be preserved as it is and should be passed to the client unmodified.

[yaacovCR]

Can you share a full reproduction? It looks like your remote errors are from different items in the list and don’t have full paths. Maybe that’s part of it.

[guifeliper]

Hello @yaacovCR, thank you so much for your answer, and I am sorry for the delay to reply.
I have been studying this issue for the past few days, and I have made some discoveries. They are the following:
1 - The underlying schema contains a contract issue.
The underlying schema is not respecting it is own contract. The contract does not allow null as an answer. However, the resolver keeps sending null objects in the data and only returns a small error/warning instead of entirely blocking the request.

For example, the docs say: country: [Country!]!, and it returns:

  "errors": [
    {
      "message": "Something broken",
      "path": [
        "country",
        3
      ]
    },
    {
      "message": "Something broken 1",
      "path": [
        "country",
        4
      ]
    }
  ],
  "data": {
    "country": [
       ...
      {
        "code": "PT",
        "name": "Portugal"
      },
      null,
      null,
      {
        "code": "RO",
        "name": "Italy"
      }
    ]
  }
}

This GraphQL API does not use GraphqlTools, so it is not something GQLtools would fix. However, this leads us to our issue.

2 - The stitching schema concatenates underlying error messages.
Once I stitch a schema, I reimplement its contract in my API layer. Once one resolver does not respect the contract, I would expect a message from my layer describing that the contract is violated. If it has any error from the underlying schema, this is also shown.

Expected result:

{
  "errors": [
    {
      "message": "Cannot return null for non-nullable field Query.country.",
      "path": [
        "country",
        3
      ]
    },
      {
      "message": "Something broken",
      "path": [
        "country",
        4
      ]
    },
  ],
  "data": null
}

Actual result:

{
  "errors": [
    {
      "message": "Something broken",
      "path": [
        "country",
        3
      ]
    }
  ],
  "data": null
}

If the actual result, you do not have the complete picture of the error, as we receive the custom message from the underlying schema and not the broke of contract.

You can see and test our current setup here: https://stackblitz.com/edit/graphql-wcfhp4?file=index.js.

[yaacovCR]

I think we just do the same thing graphql js does in this case, ie show the original error https://github.com/graphql/graphql-js/blob/5caff039f1f6df0ae85a58c2e1f682804eddce67/src/execution/__tests__/nonnull-test.ts#L193

[guifeliper]

Oh, I see. However, does it makes sense to show only the first error and not the whole tree?
Maybe we throw an error when we find one, so this makes sense, but do we throw an error? That is why we don't show the whole list of errors?

[Grmiade]

Could it be related to this issue with a reproduction test?
#3880

[guifeliper]

Thank you @Grmiade, I don't believe it is the same thing.
However, I have created a test environment maybe this is useful for you: https://stackblitz.com/edit/graphql-wcfhp4?file=index.js