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

Using @entityResolver(multi: true) causes "directive entityResolver is not implemented" to be thrown when the entity is used in another Query #3160

Open
RyanMcCabe-catapult opened this issue Jun 25, 2024 · 1 comment

Comments

@RyanMcCabe-catapult
Copy link

RyanMcCabe-catapult commented Jun 25, 2024

What happened?

I have a shared entity between two subgraphs, to keep things simple I'll call them the List service and the Item service.
Items can be retrieved in 3 ways:

  1. Items may appear as a collection of Items under a List (a federated entity between the List and Item services)
  2. They may be queried for against the Item service using some filters (Query definition: items(filter: ItemsFilter!):ItemPage)
  3. They may be queried for directly against the Item service if the ID is known (Query definition: item(id:ID!): Item)

I've set these up using the directive @key(fields: "id") and everything works as expected.
The requests to resolve large lists of items was a performance concern as each item was being resolved with a single request to the Item service, so in order to reduce this to a single call I introduced the @entityResolver(multi: true) directive to the entity definition in the Item service. This worked fine for the federated calls and only a single request was being made to resolve multiple Item IDs (scenario 1).
However in scenario 2 and 3 I'm now getting a Failed to query 'items': directive entityResolver is not implemented and a Failed to query 'item': directive entityResolver is not implemented error message for the corresponding queries.
From debugging the generated code, it seems that for scenario 2 the correct item filter resolver is called and returns the data, it then tries to resolve the fields and throws the error. For scenario 3, the item by id resolver is never called and the error is thrown.

What did you expect?

I expected the queries in scenarios 2 and 3 above to continue working after the @entityResolver(multi: true) directive was introduced.

Minimal graphql.schema and models to reproduce

If the resolvers are generated for the following, the single resolver query will work as expected, the multi resolver query will show the issue.

type RegularEntity @key(fields: "id") {
    id: ID!
    Name: String!
}

type RegularEntityWrapper {
    id: ID!
    Name: String!
    Entity: RegularEntity!
}

type MultiResolverEntity @key(fields: "id") @entityResolver(multi: true) {
    id: ID!
    Name: String!
}

type MultiResolverEntityWrapper {
    id: ID!
    Name: String!
    Entity: MultiResolverEntity!
}

type Query {
    singleResolver: RegularEntityWrapper
    multiResolver: MultiResolverEntityWrapper
}

versions

  • gqlgen v0.17.45
  • go1.22.2 darwin/arm64
@markkrijgsman
Copy link

markkrijgsman commented Jul 18, 2024

I have the same issue, my minimum schema is as follows:

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

directive @entityResolver(multi: Boolean) on OBJECT

type RecursiveEntity @key(fields: "id") @entityResolver(multi: true) {
    id: ID!
    children: [RecursiveEntity!]
}

The following query works:

query ($representations: [_Any!]!) {
  _entities(representations: $representations) {
    ... on RecursiveEntity {
      id    
    }
  }
}

But as soon as the children are requested, the request fails:

query ($representations: [_Any!]!) {
  _entities(representations: $representations) {
    ... on RecursiveEntity {
      id
      children {
        id
      }
    }
  }
}

Variables payload is the same for both requests:

{
  "representations": [
    {
    "__typename": "RecursiveEntity",
    "id": "42"
    }
  ]
}

I'm using gqlgen v0.17.43 on Go 1.21.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants