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

Fix issue when type is only reachable through a @provides #2083

Merged
merged 2 commits into from
Aug 23, 2022

Conversation

pcmanus
Copy link
Contributor

@pcmanus pcmanus commented Aug 19, 2022

It's possible for a type within a subgraph to be only "reachable" through
a provides. Consider:

type Query {
  t: T @provides(fields: "a { ... on A { x }}")
}

type T @key(fields: "id") {
  id: ID!
  a: A @external
}

type A {
  x: Int
}

In that case, type A is only mentioned by external field T.a, and
as he code was completely ignoring external fields, that type A was
not added to the underlying "query graph". But that type is reachable
through the @provides on Query.t, and as we were trying to handle
that @provides, we were running into an assertion error due to A
not existing in the "query graph".

This patch ensures that when we have an external field, even if we don't
add any edges, we at least add the target type to the "query graph",
ensuring it exists later as we handle @provides.

Fixes #1935

@netlify
Copy link

netlify bot commented Aug 19, 2022

👷 Deploy request for apollo-federation-docs pending review.

Visit the deploys page to approve it

Name Link
🔨 Latest commit 78472c2

@codesandbox-ci
Copy link

codesandbox-ci bot commented Aug 19, 2022

This pull request is automatically built and testable in CodeSandbox.

To see build info of the built libraries, click here or the icon next to each commit SHA.

Sylvain Lebresne added 2 commits August 23, 2022 11:11
It's possible for a type within a subgraph to be only "reachable" through
a provides. Consider:
```graphql
type Query {
  t: T @provides(fields: "a { ... on A { x }}")
}

type T @key(fields: "id") {
  id: ID!
  a: A @external
}

type A {
  x: Int
}
```
In that case, type `A` is only mentioned by external field `T.a`, and
as he code was completely ignoring external fields, that type `A` was
not added to the underlying "query graph". But that type _is_ reachable
through the `@provides` on `Query.t`, and as we were trying to handle
that `@provides`, we were running into an assertion error due to `A`
not existing in the "query graph".

This patch ensures that when we have an external field, even if we don't
add any edges, we at least add the target type to the "query graph",
ensuring it exists later as we handle `@provides`.

Fixes apollographql#1935
@pcmanus pcmanus force-pushed the f1935-fragment-in-provides branch from 0134ec6 to 78472c2 Compare August 23, 2022 09:13
@pcmanus pcmanus merged commit b7e788e into apollographql:main Aug 23, 2022
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

Successfully merging this pull request may close these issues.

Unable to start gateway when schema uses fragment in @provides
2 participants