fix for codegen rejecting operations that contain fragments with type conditions on interfaces

[dsnam]

Description

Given a schema like this:

type Query {
    foo: Foo
}

interface Foo {
    fooField: String!
}

interface Bar implements Foo {
    fooField: String!
    barField: String!
}

type Baz implements Bar & Foo {
    barField: String!
    fooField: String!
}

codegen would reject queries with fragments like this:

foo {
    fooField
    ... on Bar {
        barField
    }
}

=========================== short test summary info ============================
FAILED tests/test_operation_codegen.py::test_operation_gen_nested_interface - SystemExit: type Bar not possible for Foo at tests/test-schemas/op-gen.gql:3:9
========================= 1 failed, 94 passed in 1.49s =========================

The check for whether or not a type in a type condition was valid was only based on the interface's possibleTypes, which cannot include other interfaces. This adds checking whether the type implements the interface. I believe interfaces used to not be allowed to implement interfaces according to the spec, but this was added some time ago.

Related Issues

I did not open an issue or spot a related one. If there are issues with the approach in this PR I can close this and open an issue instead to keep track of it.

Progress

Pull request checklist

• Tests: This PR includes tests for covering the features or bug fixes (if applicable).
• Docs: This PR updates/creates the necessary documentation.
• CI: Make sure your Pull Request passes all CI checks. If not, clarify the motif behind that and the action plan to solve it (may reference a ticket)

How to test it

I added a test that uses a schema and operation file in this PR that reproduces the issue.

[dsnam]

@barbieri any chance you will have time to take a look at this soon?

[barbieri]

sorry taking so long (busy at work), I'll look at it during the weekend. Thanks for your contribution!!!

[barbieri]

just a heads up I didn't forget about this, seems the CI is broken unrelated to this PR... I'll disable older python to see if that comes back to work

[barbieri]

sorry, I did click the "update branch as merge", but can you do a rebase? Let me know if that works for you

[coveralls]

Pull Request Test Coverage Report for Build 10851448875

Details

• 0 of 0 changed or added relevant lines in 0 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage remained the same at 100.0%

---

Totals
Change from base Build 10801456318:	0.0%
Covered Lines:	1615
Relevant Lines:	1615

---

💛 - Coveralls

[dsnam]

sorry, I did click the "update branch as merge", but can you do a rebase? Let me know if that works for you

Yep, had to reinstall deps to get the pre-commit tests passing but I think it's set now.

[barbieri]

I'll approve, but let me know if you can convert this test to be more self contained, instead of using external files. Declare a minimal subset as strings in this file.

Also, I think it would be great to check the generated result_buff to make sure it's what we expect :-)

[dsnam]

Yep I can do that, I will try to get to it today or a bit later on the weekend.

[dsnam]

@barbieri I cut out a lot of the introspection output to try and keep the inlined resource small, namely the metadata about builtin things like the __Schema and __Type types that describe what comes back in the introspection query itself and things related to directives. The test still ran fine, but do you think that may cause an issue later or do you not anticipate the codegen ever caring about that? Trying to avoid some future change suddenly breaking this test due to it having an incomplete introspection output.

[barbieri]

thanks!

[barbieri]

https://pypi.org/project/sgqlc/16.4/