Nested resolvers from different subgraphs

[Ty3uK]

Hello!

I have two subgraphs (simplified):

First subgraph:

type Error {
    message: String!
}

type CaptchaVerifyInput {
    token: String!
    text: String!
}

type CaptchaVerifyResult {
    error: Error
    mutation: Mutation
}

type Mutation {
    verifyCaptcha(input: CaptchaVerifyInput!): CaptchaVerifyResult
}

Second subgraph:

type Error {
    message: String!
}

type Item {
    id: ID!
    title: String!
}

type UpdateItemInput {
    id: ID!
    title: String!
}

type UpdateItemResult {
    record: Item
    error: Error
}

type Mutation {
    updateItem(input: UpdateItemInput!): UpdateItemResult
}

After composing, I can do next thing:

mutation UpdateItem {
    verifyCaptcha(input: {
        token: "foo",
        text: "bar",
    }) {
        mutation {
            updateItem(input: {
                id: "1",
                title: "Changed!",    
            }) {
                record {
                    id
                    title
                }
                error {
                    message
                }
            }
        }
    }
}

In first subgraph I return null in mutation if captcha isn't verified. And with @apollo/gateway this approach works: second subgraph resolver isn't called when first supgraph returns mutation: null. But with router resolver in second subgraph always will be called, even if mutation: null will be returned.

Can you tell me, is this bug or expected behaviour?

[Ty3uK]

As I can see, query plans are identical both at @apollo/gateway and router:

router

Sequence {
    nodes: [
        Fetch(
            FetchNode {
                service_name: "captcha",
                requires: [],
                variable_usages: [],
                operation: "mutation{verifyCaptcha(input:{token:\"2828472b-7f8b-43d9-97b6-8218d8be8cf7\" text:\"мировой\"}){error{__typename message}mutation{__typename}}}",
                operation_name: None,
                operation_kind: Mutation,
            },
        ),
        Flatten(
            FlattenNode {
                path: Path(
                    [
                        Key(
                            "verifyCaptcha",
                        ),
                        Key(
                            "mutation",
                        ),
                    ],
                ),
                node: Fetch(
                    FetchNode {
                        service_name: "items",
                        requires: [],
                        variable_usages: [],
                        operation: "mutation{...on Mutation{itemMutations{update(input:{id:1 title:\"Changed\"}){__typename}}}}",
                        operation_name: None,
                        operation_kind: Mutation,
                    },
                ),
            },
        ),
    ],
}

@apollo/gateway

QueryPlan {
  Sequence {
    Fetch(service: "captcha") {
      {
        verifyCaptcha(
          input: {token: "2828472b-7f8b-43d9-97b6-8218d8be8cf7", text: "мировой"}
        ) {
          error {
            __typename
            message
          }
          mutation {
            __typename
          }
        }
      }
    },
    Flatten(path: "verifyCaptcha.mutation") {
      Fetch(service: "items") {
        {
          ... on Mutation {
            itemMutations {
              update(input: {id: 1, title: "Changed"}) {
                __typename
              }
            }
          }
        }
      },
    },
  },
}

[abernix]

I know this is older, and I'm just doing some cleanup, but we don't have enough to reproduce this above. If you're still running into a stark difference between the Router and the Gateway in this regard, please open an issue with an easy to run reproduction. Thanks!

[Ty3uK]

I know this is older, and I'm just doing some cleanup, but we don't have enough to reproduce this above. If you're still running into a stark difference between the Router and the Gateway in this regard, please open an issue with an easy to run reproduction. Thanks!

@Geal helped me with PR, so yeah, it's old one 🙂

#1332

But thanks for the reply!