Possible difference in schema validation between DSL and import_sdl

[mattbaker]

The basic questions I'm trying to answer are:

1. Is there really is a discrepancy in schema validation between using import_sdl vs the DSL when using interfaces in a specific way?
2. If so, which one is right?

I provided a diff with a couple sample test cases in #1088 with details as well as a sample schema that should be representative of the "real one" we're working with internally.

Env

Elixir 1.12.1
PR is using Absinthe master

Expected behavior

It seems like the two modes should agree, but this is a weird case and I'll fully admit it's a bit of a tangle.

Actual behavior

import_sdl will cause a schema validation failure, while expressing what appears to be the same schema using the DSL succeeds.

@jerelmiller — curious if my test case matches what you think you're seeing as well.

[jerelmiller]

curious if my test case matches what you think you're seeing as well

That is correct! This is a good reproduction of the problem I'm seeing.

[jerelmiller]

After a bit of discussion, @emeryotopalik and I were able to setup a minimal reproduction of this schema using GraphQL.js. We were able to determine that an interface with a field that points to another interface was a valid use case.

It appears the DSL handles this correctly, which means the problem lies in the SDL import. Let's ensure the import_sdl can work with this use case as well!

[jerelmiller]

I read through a bit more of the GraphQL spec for Interfaces and found this nugget:

Fields on a GraphQL interface have the same rules as fields on a GraphQL object; their type can be Scalar, Object, Enum, Interface, or Union, or any wrapping type whose base type is one of those five.

Looks like the language used for "types match exactly" comes from the Introspection information. Not exactly sure why the introspection information isn't as clear-cut as the spec itself.