Fields on interface fragment spreads don't get resolved

[LucasPickering]

Describe the bug

When resolving fields defined on an interface, if the field is defined within a fragment spread, then it is omitted from the output.

I'm happy to work on a fix for this, but will need some guidance on where to look (and whatever other tips/hints you could give me).

To Reproduce

Using the schema defined in juniper/src/tests/fixtures/starwars/ (I ran the juniper_rocket_async example to reproduce):

Working

A simple query returns the expected result (id and name fields are populated).

query {
  hero {
    id
    name
  }
}

{
  "data": {
    "hero": {
      "id": "2001",
      "name": "R2-D2"
    }
  }
}

Broken

But this query, using a fragment spread on the Character interface, is broken (id and name fields are omitted in the response):

{
  hero {
    ... on Character {
      id
      name
    }
  }
}

{
  "data": {
    "hero": {}
  }
}

Expected behavior

The second query above should return the exact same output as the first query.

Additional context

I encountered this problem using Relay in my UI, as parts of the query being generated by Relay use this pattern. Which leads me to believe that these queries should definitely be valid.

[ArsileLuci]

This is clearly a regression from 0.15.3. I downgraded juniper and all related crates from 0.15.4 to 0.15.3 and it helped.

Also this bug can be reproduced with unions. It was an interface.

[LucasPickering]

@ArsileLuci I just tried downgrading to 0.15.3 and am still seeing the issue. If this is a regression in 0.15.4 though, I'd be willing to bet it's related to this PR: #907

[ArsileLuci]

@LucasPickering Found the issue. As You've pointed out the problem comes partially from #907

Bug was in typename matching, at this two rows.

fragment.type_condition.item is the name of interface, and it was compared with instance.concrete_type_name(sub_exec.context(), info) which is actually exact name of the type that implements interface.

I have a fix for this, and now preparing tests to eliminate all possibilities of this reoccurring

[LucasPickering]

@ArsileLuci nice find! thank you so much for finding+fixing that, much appreciated

[tyranron]

@LegNeato would you be so kind to produce a release? This regression is quite a pain-in-ass.