Inline fragments are only evaluated against the first subschema containing the merge type #4966

Activity

1. metallicOxide commented on Aug 8, 2023

   

   metallicOxide

   on Aug 8, 2023

   Last edited by metallicOxide

   More actions

   Hi 👋, we have experienced a similar issue with stitching...

   Please see a replication of this issue here https://github.com/metallicOxide/type-merging-interfaces
   Interestingly, the issue was not present on v7.1 of @graphql-tools/stitch but became present from v8 onwards...

   We discovered that with the type merging approach described here the inline fragments were not evaluated and returning null.
   https://the-guild.dev/graphql/stitching/docs/approaches/type-merging#:~:text=Type%20merging%20allows%20partial%20definitions,type%20in%20the%20gateway%20schema.

   We were able to get around this issue by using schema-extensions instead however this is not ideal as we had to create stub types which we extended. The approach is described here -> https://the-guild.dev/graphql/stitching/docs/approaches/schema-extensions#basic-example
2. hedgepigdaniel commented on Aug 9, 2023

   

   hedgepigdaniel

   on Aug 9, 2023

   More actions

   One possible workaround is to avoid merging union/interface types between two schemas, and instead add the fields that refer to them to the stitched schema, along with a resolver that delegates to the appropriate subschema. Something like this:

   let studentSchema = makeExecutableSchema({
     typeDefs: /* GraphQL */ `
       type Query {
         student(id: String!): Student
       }
       type Student {
         id: String!
         name: String!
         # major: Major ## Add this later, in stitching
       }
     `,
   });
   
   let majorsSchema = makeExecutableSchema({
     typeDefs: /* GraphQL */ `
       type Query {
         major(id: String!): Major @merge(keyField: "id")
       }
       union Major = MajorError | MajorSuccess # Allow for different return values
       type MajorError {
         id: String!
         code: String!
       }
       type MajorSuccess {
         id: String!
         name: String!
       }
     `,
   });
   
   stitchSchemas({
     subschemas: [studentSchema, majorsSchema],
     typeDefs: `extend type Student { major: Major}`,
     resolvers: {
       Student: {
         major: {
           selectionSet: forwardArgsToSelectionSet('{ id }'),
           resolve: (
             selections: { id: string },
             args,
             context,
             info,
           ) => delegateToSchema({
             schema: majorsSchema,
             operation: OperationTypeNode.QUERY,
             fieldName: 'major',
             args: {
               id: selections.id,
             },
             context,
             info,
           }),
         },
       },
     },
   });
3. metallicOxide commented on Aug 9, 2023

   

   metallicOxide

   on Aug 9, 2023

   More actions

   One of the things that also worked for me was making a direct call to delegateToSchema in the resolve key in merge.

   let studentSchema = makeExecutableSchema({
     typeDefs: /* GraphQL */ `
       type Query {
         student(id: String!): Student
       }
       type Student {
         id: String!
         name: String!
         major: Major 
       }
     `,
   });
   
   let majorsSchema = makeExecutableSchema({
     typeDefs: /* GraphQL */ `
       type Query {
         major(id: String!): Major
       }
       union Major = MajorError | MajorSuccess # Allow for different return values
       type MajorError {
         id: String!
         code: String!
       }
       type MajorSuccess {
         id: String!
         name: String!
       }
     `,
     merge: {
       Major:  {
         selectionSet: '{id}',
         resolve(model, context, info, subschema) {
             return delegateToSchema({
               schema: subschema,
               operation: OperationTypeNode.QUERY,
               fieldName: 'major',
               args: {id: model.id},
               context,
               info,
               skipTypeMerging: true,
             });
         }
       }
     }
   });
   

   Strange enough, passing in the 5th argument in resolve (selectionSet) into batchDelegateToSchema actually breaks this...
4. ardatan

   closed this as completedon Oct 20, 2026
5. ardatan

   reopened this on Oct 20, 2026
6. ardatan commented on Oct 22, 2026

   

   ardatan

   on Oct 22, 2026

   Owner

   More actions

   Fixed in Hive Gateway via graphql-hive/gateway#2671 (merged).

   Union @merge now registers the abstract type, and nested inline-fragment spreads are flattened so merge keys are queried across subschemas. Closing this issue.
7. ardatan

   closed this as completedon Oct 22, 2026