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

Gateway throws error for @provides-directive on interfaces and objects implementing interfaces #2987

Closed
ddubbert opened this issue Jul 4, 2019 · 2 comments
Labels
⛲️ feature New addition or enhancement to existing solutions

Comments

@ddubbert
Copy link

ddubbert commented Jul 4, 2019

Since @apollo/gateway version 0.6.12, when using the @provides-directive on an interface or an object type implementing an interface, the gateway throws an error.

Last working version: 0.6.11

Expected behavior: The @provides-directive should work on fields of interfaces and object types, as long as the type has a @key-directive.

Actual behavior: The gateway throws following errors:

// User is an interface

GraphQLSchemaValidationError: [products] Product.producer -> uses the @provides directive but Product.producer returns User!, which is not an Object type. @provides can only be used on Object types with at least one @key.

or

// Producer is an object type implementing User

GraphQLSchemaValidationError: [products] Product.producer -> uses the @provides directive but Product.producer returns Producer!, which is not an Object type. @provides can only be used on Object types with at least one @key.

The stacktrace is as follows:

at ApolloGateway.createSchema (.../node_modules/@apollo/gateway/dist/index.js:92:19)
    at ApolloGateway.<anonymous> (.../node_modules/@apollo/gateway/dist/index.js:81:22)
    at Generator.next (<anonymous>)
    at fulfilled (.../node_modules/@apollo/gateway/dist/index.js:4:58)
    at process._tickCallback (internal/process/next_tick.js:68:7)

Reproduction: https://github.com/ddubbert/gateway-provides-issue

Short Type summary: The corresponding type definitions look like this (unnecessary fields were excluded):

// User-Service types

interface User @key(fields: "id") {
    id: ID!
    member_since: DateTime!
    username: String!
}

type Producer implements User @key(fields: "id") {
    id: ID!
    member_since: DateTime!
    username: String!
}
// Product-Service types when extending Producer
extend type Producer @key(fields: "id") {
  id: ID! @external
  username: String! @external
}

type Product @key(fields: "id"){
    id: ID!
    name: String!
    producer: Producer! @provides(fields: "username")
}

// Product-Service types when extending User
extend interface User @key(fields: "id") {
  id: ID! @external
  username: String! @external
}

type Product @key(fields: "id"){
    id: ID!
    name: String!
    producer: User! @provides(fields: "username")
}
@martijnwalraven martijnwalraven added the ⛲️ feature New addition or enhancement to existing solutions label Jul 8, 2019
@martijnwalraven
Copy link
Contributor

You're right, these are indeed limitations of the current schema composition and query planning implementations: interfaces do not support @key directives, and you can't use @provides on fields that return an interface type. We definitely intend to support this in the future however.

@ddubbert
Copy link
Author

You're right, these are indeed limitations of the current schema composition and query planning implementations: interfaces do not support @key directives, and you can't use @provides on fields that return an interface type. We definitely intend to support this in the future however.

Well, it worked on object-types that were implementing an interface (in 0.6.11 downwards) but stopped working since 0.6.12. What about that? Why did it work before?

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Apr 21, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
⛲️ feature New addition or enhancement to existing solutions
Projects
None yet
Development

No branches or pull requests

3 participants