Derived schema produces incorrect error response

[rvanheest]

I'm working on refactoring one of my GraphQL implementations from manually defining Field and Argument instances to the annotation based style with @GraphQLField and so on. I managed to get it working exactly as before, except for one small piece. I suspect this to be a bug in the derivation package of Sangria, but I'm not sure where exactly.

Suppose I have a query (returning an error) like

query {
    foo {
        bar
    }
}

In the 'old' style, I received the following JSON. Notice that the path list contains all the elements up to the error. Because the result for foo could not be calculated, it's value in the JSON below is null.

{
  "data": {
    "foo": null
  },
  "errors": [
    {
      "message": "<some message>",
      "path": [
        "foo"
      ],
      "locations": [
        {
          "line": 2,
          "column": 5
        }
      ]
    }
  ]
}

However, after the refactoring, I get the same path list, but the data is now null, rather than being an object with { "foo": null }. The error caused the result to move 'one level up', so to speak.

{
  "data": null,
  "errors": [
    {
      "message": "<some message>",
      "path": [
        "foo"
      ],
      "locations": [
        {
          "line": 2,
          "column": 5
        }
      ]
    }
  ]
}

This is also the case with a deeper nested example. The query below is supposed to result in an error on bar.

query {
    foo {
        bar {
            baz
        }
    }
}

In the 'old' implementation the path to the error within the data object is consistent with the path list.

{
  "data": {
    "foo": {
      "bar": null
    }
  },
  "errors": [
    {
      "message": "<some message>",
      "path": [
        "foo",
        "bar"
      ],
      "locations": [
        {
          "line": 3,
          "column": 9
        }
      ]
    }
  ]
}

However, using the implementation derived from annotations, the bar is missing again from the data object, while it is still listed in path.

{
  "data": {
    "foo": null
  },
  "errors": [
    {
      "message": "<some message>",
      "path": [
        "foo",
        "bar"
      ],
      "locations": [
        {
          "line": 3,
          "column": 9
        }
      ]
    }
  ]
}

[nickhudkins]

Hi @rvanheest any chance we could get a simplified test case producing this error? This behavior looks to be one that could absolutely be an inadvertent Non-nullable field in the chain.

The GraphQL spec defines this behavior here: https://spec.graphql.org/October2016/#sec-Errors-and-Non-Nullability

So what I expect is happening is that in the "old" example, bar is nullable, and the "new" example, bar is not nullable, and so the error walks its way up to the closest nullable parent. In this case... foo.

Happy to help if you can put together a simple example (full code please!)