Resolvers after calling stitchSchemas doesn't have access to the query aliases anymore

[Rowadz]

Hey, I was using the stitchSchemas function, and I've noticed that the info object passed to the resolvers doesn't point to the alias from the GraphQL query anymore, is this a known issue or something intentional? ('info.path.key' is not correct)

I have a simple example here in this repo

If I send this query with aliases the resolver for the user field will not have the information about the aliases userAlias01 and userAlias02, in both cases it will point to user.

This is not the case without using stitchSchemas, any idea of what can I do here? or if this is a bug or not

query users {
  userAlias01: user(id: 1) {
    id
    name
  }
  userAlias02: user(id: 2) {
    id
    name
  }
}

This might be similar #1819

[Rowadz]

TL;DR

Pass batch: true to the main and subschemas to fix this

For anyone who stumbled upon this in the future

This only happens at the root level AND only if the passed schema config doesn't use the 🟣 batching feature 🟣, I'm not sure why exactly.

So for the below code, the schema I'm passing will be treated like a subschema and internally the proxied resolvers will send a single request for reach root level using the executor you passed at some points

For the below code

export const gatewaySchema = stitchSchemas({
  subschemas: [schema],
})

const yoga = createYoga<GraphQLContext>({
  schema: gatewaySchema,
})

with this query:

query users{
  user_with_id_01 :user(id:1){
    id

    name
  }
  user_with_id_02 :user(id:2){
    id
    posts {
      title
    }
    name
    nextUser03: nextUser {
      id
    }
  }
}

The stitching at some point calls the user resolver twice and removes the aliases (for some reason) and the only way to fix it as far as I know, is to enable batching like so

export const gatewaySchema = stitchSchemas({
  subschemas: [{ schema, batch: true }],
})

const yoga = createYoga<GraphQLContext>({
  schema: gatewaySchema,
})

Like this you get an alias passed for each resolver call, it won't be the alias passed by the client, but it will be unique, however, I really can't see any difference in the way resolvers are called, and I don't know what's going on internally, but this fixed my issue, and nothing seems to be different

I'll open a PR in the future to maybe add this part of the docs for others to notice