Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

query execution error when using @interfaceObject #2743

Closed
maxrad82 opened this issue Aug 22, 2023 · 0 comments · Fixed by #2778
Closed

query execution error when using @interfaceObject #2743

maxrad82 opened this issue Aug 22, 2023 · 0 comments · Fixed by #2778
Assignees
Labels
🪲 bug P2 An issue that needs to be addressed on a reasonable timescale.

Comments

@maxrad82
Copy link

maxrad82 commented Aug 22, 2023

Issue Description

I'm experiencing a very strange behaviour using the @interfaceObject directive

Considering 3 services

Service 1:

        extend schema
        @link(url: "https://specs.apollo.dev/federation/v2.3",
            import: ["@key"])

        interface Product @key(fields:"id") {
            id: ID!
        }

        type Book implements Product @key(fields:"id") {
            id:ID!
            title: String
        }

        type Query {
            allProducts: [Product!]!
        }

Service 2:

        extend schema
        @link(url: "https://specs.apollo.dev/federation/v2.3",
            import: ["@key", "@interfaceObject"])

        type Product @key(fields:"id") @interfaceObject {
            id: ID!
            reviews: [String!]!
        }

Service 3:

        extend schema
        @link(url: "https://specs.apollo.dev/federation/v2.3",
            import: ["@key", "@interfaceObject"])

        type Product @key(fields:"id") @interfaceObject {
            id: ID!
        }

        type Query {
            searchProducts: [Product!]!
        }

depending on the query, it may failed, suceed or be inconsistant

  searchProducts {
    id
    reviews    
  }

=> ok

  searchProducts {
    __typename
    id
    reviews    
  } 

=> error "Cannot return null for non-nullable array element of type Product at index 0"

  searchProducts {
    id
    ...on Book {
      reviews
    }    
  }

=> inconsistant result, missing reviews field

I have linked a github repo to reproduce this issue. I'm pretty sure the implementation is correct according the documentation

Link to Reproduction

https://github.com/maxrad82/apollo-federation-bug-interface

Reproduction Steps

Prerequisite:

  • docker
  • docker-compose
  • rover

clone the repository and run make run to start the subgraphs and the supergraph
go to http://localhost:4007

run the followng queries:

query ExampleQuery {  
  searchProducts {
    id
    reviews
  }
}

=> ok

query ExampleQuery {  
  searchProducts {
   __typename
    id
    reviews
  }
}

=> fails

query ExampleQuery {  
  searchProducts {
    id
    ...on Book {
      reviews
    }    
  }
}

=> reviews is not return

@korinne korinne added the P2 An issue that needs to be addressed on a reasonable timescale. label Aug 25, 2023
trevor-scheer added a commit that referenced this issue Sep 14, 2023
Fix specific case for requesting `__typename` on interface entity type

In certain cases, when resolving a `__typename` on an interface entity (due
to it actual being requested in the operation), that fetch group could
previously be trimmed / treated as useless. At a glance, it appears to be a
redundant step, i.e.:
```
{ ... on Product { __typename id }} => { ... on Product { __typename} }
```
It's actually necessary to preserve this in the case that we're coming from an
interface object to an (entity) interface so that we can resolve the concrete
`__typename` correctly.

Ref: #2743 (this fixes one of the queries from the issue but not both)
trevor-scheer added a commit that referenced this issue Sep 15, 2023
…#2778)

In certain cases, the query planner was preserving some fetches which were "useless"
that would rewrite `__typename` from its already-resolved concrete type back to its
interface type. This could result in (at least) requested fields being "filtered" from the
final result due to the interface's `__typename` in the data where the concrete type's
`__typename` was expected.

Specifically, the solution was compute the path between newly created groups and
their parents when we know that it's trivial (`[]`). Further along in the planning
process, this allows to actually remove the known-useless group.

Fixes #2743 (pt 2)

Co-authored-by: Sylvain Lebresne <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
🪲 bug P2 An issue that needs to be addressed on a reasonable timescale.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants