Stitcher does not resolve when using fragment in query

[MaxBerendsBS]

When stitching two services together that use (near) equal types the resolve function won't function properly.
Below you'll find an example setup. When running the query t1 will return the correct response, however t2 will return null and not reach the Shop service. I can see that is goes trough the custom resolver, and that the query is build.

What's odd is that for t2 the delegateToSchema will be called twice (once from the resolver and once from the graphql execute). And the second time it does not have the (correct) params.

I know its better to use Shop_Book as a result type, but in this case it should not matter as they are equal, and makes it easier for a single fragment.

Shop

Schema

type Book {
    id: ID!
    name: String
}

type Query {
  topBook(shelfId: ID): Book
}

Transforms

new RenameTypes((name) => `Shop_${name}`)

Library

Schema

type Book {
    id: ID!
    name: String
}

type Shelf {
    id: ID!
    books: [Book]
}

type Query {
  getShelf(id: ID!): Shelf
}

Transforms

new RenameTypes((name) => `Library_${name}`)

Links

extend type Library_Shelfs {
    topBook: Library_Book
}

Resolver

Library_Shelf: {
    highlight: {
        fragment: `... on Shelf { id }`,
        resolve(shelf, args, context, info) {
            return info.mergeInfo.delegateToSchema({
                schema: [[Shop Schema]],
                operation: 'query',
                fieldName: 'topBook',
                args: {
                    shelfId: shelf["id"]
                },
                context,
                info
            });
        }
    }
}

Query

fragment Book on Library_Book {
    name
}

query {
  getShelf {
    t1: topBook{
        name
    }
    t2 {
        ...Book
    }
    books {
        ...Book
    }
  }
}

[kommander]

I am pretty sure this is because mergeSchemas is trying to be smart as well, like #1033 and #1035. Can you try to reproduce that with this as a template for investigation?

[yaacovCR]

Not sure about this one, possibly solved, vs I am missing something. Closing for now, please reopen if relevant with a minimally reproducing repository based on above.

[macrozone]

@yaacovCR seems to happen still on version 6.0.12

when i query data from a stitched schema using fragments, i get null as result, wheras if i dont use fragments, i get the proper data:

does not work:

{
  topBrands { # of type Brand, from Schema A
    assortment { # this is stitched in into from schema B
      ...MyFragment
    }
  }
}

fragment MyFragment on ShopAssortment {
  _id
}

does work:

{
  topBrands { # of type Brand, from Schema A
    assortment { # this is stitched in into from schema B
      _id
    }
  }
}

[yaacovCR]

This would be a serious bug that I would want to fix asap.

Can you reopen as a new issue with a full minimal example either within the issue or as a separate GitHub repository?

Even better would be a PR with a failing test case.

I believe we have some tests with fragments, so I am surprised this is not working, but a gaping hole in our test coverage would also not be a surprise...

[macrozone]

i could solve it. For reference:

It happened because i applied a transform using stitchSchemas where you can specify

{
 schema: yourSchema,
 transform: [...]
}

If you do so, be careful with delegateToSchema({schema: ... }), if you do delegateToSchema({schema: yourSchema }) you will get this error. https://www.graphql-tools.com/docs/schema-stitching explains how to do it correctly

const yourSchemaWithTransforms = {
 schema: yourSchema,
 transform: [...]
}

and then

delegateToSchema({schema: yourSchemaWithTransforms })