# Apollo Gateway 2.x broke Node resolver pattern

**URL:** <https://community.apollographql.com/t/apollo-gateway-2-x-broke-node-resolver-pattern/3804>\
**Category:** Server\
**Tags:** server, federation\
**Created:** [June 20, 2022, 11:05am UTC](https://community.apollographql.com/t/apollo-gateway-2-x-broke-node-resolver-pattern/3804 "2022-06-20T11:05:22Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![jukben](https://sea1.discourse-cdn.com/flex019/user_avatar/community.apollographql.com/jukben/32/2567_2.png) [@jukben](https://community.apollographql.com/u/jukben)\
**Post date:** [June 20, 2022, 11:05am UTC](https://community.apollographql.com/t/apollo-gateway-2-x-broke-node-resolver-pattern/3804/1 "2022-06-20T11:05:22Z")

</div>

Hey, try this forum to get some help. The whole issue is described in this issue:

> <https://github.com/apollographql/federation/issues/1917#issuecomment-1160041300>
>
> I am running into a problem when running a query of a shared interface that is a…lso a field on \`Query\`.
> 
> Essentially, it appears that something is causing confusion in the query plan where the query plan is defaulting to a particular subgraph. If that subgraph does not have the implementation of the type, it drops the union/fragment.
> 
> We have built a plugin with logic that can analyze the \`id\` and point the query to the correct subgraph, and can get a return on the gateway, but when the gateway returns the the client, the result is \`null\`. I assume this is because the gateway is attempting to return a type belonging to the "default" subgraph instead of the correct subgraph and something is failing.
> 
> I have seen some recent PRs that impact the query plan - was not sure if this may be related.
> \- https://github.com/apollographql/federation/pull/1911
> \- https://github.com/apollographql/federation/pull/1859
> 
> Also entirely possible that I've misunderstood how to decorate these types/fields, so could be human error.
> 
> Happy to provide more details, but didn't want to overwhelm with a wall of output.
> 
> \### Reproducable example
> 
> Subgraph 1
> \`\`\`
> extend schema
> @link(url: "https://specs.apollo.dev/federation/v2.0",
> import: \["@key", "@shareable"\])
> 
> interface Node {
> id: ID!
> }
> 
> type Query {
> node(id: ID!): Node @shareable
> }
> \`\`\`
> 
> Subgraph 2
> \`\`\`
> extend schema
> @link(url: "https://specs.apollo.dev/federation/v2.0",
> import: \["@key", "@shareable"\])
> 
> interface Node {
> id: ID!
> }
> 
> type Foobar implements Node {
> id: ID!
> 
> uuid: String!
> version: Int!
> name: String!
> description: String
> category: \[String!\]
> }
> 
> type Query {
> node(id: ID!): Node @shareable
> }
> \`\`\`
> 
> Supergraph (partial/relevant bits - I can share more if helpful)
> \`\`\`
> enum join\_\_Graph {
> SUBGRAPH1 @join\_\_graph(name: "subgraph1", url: "https://path.com")
> SUBGRAPH2 @join\_\_graph(name: "subgraph2", url: "https://otherpath.com")
> }
> 
> interface Node
> @join\_\_type(graph: SUBGRAPH1)
> @join\_\_type(graph: SUBGRAPH2)
> {
> id: ID!
> }
> 
> type Foobar implements Node
> @join\_\_implements(graph: SUBGRAPH2, interface: "Node")
> @join\_\_type(graph: SUBGRAPH2)
> {
> id: ID!
> uuid: String!
> version: Int!
> name: String!
> description: String
> category: \[String!\]
> }
> 
> type Query
> @join\_\_type(graph: SUBGRAPH1)
> @join\_\_type(graph: SUBGRAPH2)
> {
> node(id: ID!): Node
> }
> 
> \`\`\`
> 
> Query (from client)
> \`\`\`
> query SampleQuery($id: ID!) {
> node(id: $id) {
> \_\_typename
> id
> ... on Foobar {
> uuid
> }
> }
> }
> \`\`\`
> 
> QueryPlan (should be subgraph2)
> \`\`\`
> QueryPlan {
> Fetch(service: "subgraph1") {
> {
> node(id: $id) {
> \_\_typename
> id
> }
> }
> },
> }
> \`\`\`

Let me know if you would like to pair-program or whatever!