Mocking: Resolving a union throws an error

[nemonemi]

Describe the bug

Without the union return type, everything works, but when having a union as a return type it throws an error.

To Reproduce Steps to reproduce the behavior:

1. Clone the https://github.com/nemonemi/mesh_gateway (yarn berry)
2. Install dependencies
3. Run yarn start
4. Visit http://localhost:4000
5. Use the uploadFile mutation. -> it works
6. Use the uploadFileWithUnion mutation. -> throws an error

"message": "Abstract type \"UploadFileResult\" must resolve to an Object type at runtime for field \"Mutation.uploadFileWithUnion\". Either the \"UploadFileResult\" type should provide a \"resolveType\" function or each possible type should provide an \"isTypeOf\" function.",

This is the resolver:

export default {
  uploadFile: () => {
    return {
      __typename: 'UploadFile',
      fileID: datatype.uuid()
    }
  },
  uploadFileWithUnion: (_, {value}) => {
    if (value !== 'valid') {
      return {
        __typename: 'WrongFileTypeError',
        message: 'Nope...'
      }
    }
    return {
      __typename: 'UploadFile',
      fileID: datatype.uuid()
    }
  }
};

Expected behavior

It should work.

Question It suggest using the resolveType or isTypeOf. How can one provide those methods from within the graphql-mesh resolvers?

[dotansimha]

@ardatan thoughts?

[paradigm314]

@ardatan @dotansimha

I am getting a similar issue attempting to replace an openapi handler field that is generated as JSON with an Interface.

Generated Source Type

OrganizationsOrganizationProfiles {
  data: [JSON]
}

Replace-Field Transform

- replace-field:
     typeDefs: ./src/organizationsTypeDefs.graphql
     replacements:
       - from:
            type: OrganizationsOrganizationProfiles
            field: data
          to:
            type: OrganizationProfilesResponse
            field: data

organizationsTypeDefs

type OrganizationProfilesResponse {
    data: [OrganizationProfile]
}

interface OrganizationProfile {
    id: String
    organizationId: String
    type: String
}

type LocationProfile implements OrganizationProfile {
    id: String
    organizationId: String
    type: String
    status: Status2
    address_line_1: String
    address_line_2: String
    city: String
    state: String
    postal_code: String
    country: String
    timezone: String
    latitude: Int
    longitude: Int
}

type VideoContentProfile implements OrganizationProfile {
    id: String
    organizationId: String
    type: String
    status: Status2
    maxContent: Int
    scope: String
}

The typing works correctly but when it's resolved throws the same error.

Abstract type "OrganizationProfile" must resolve to an Object type at runtime for field "OrganizationsOrganizationProfiles.data". Either the "OrganizationProfile" type should provide a "resolveType" function or each possible type should provide an "isTypeOf" function.

I have tried adding the __resolveType via both addtionalResolvers and extend transform but the error remains.

Attempted Additional Resolver

import { Resolvers } from '@mesh/index';

export const resolvers: Resolvers = {
  OrganizationProfile: {
    __resolveType: (obj, context, info) => {

      if (obj.type === 'organizations.organization_profiles.VideoContentProfile') {
        return 'VideoContentProfile'
      }

      if (obj.type === 'organizations.organization_profiles.LocationProfile') {
        return 'LocationProfile'
      }

      return null
    }
  },
};

[caribouflex]

Hello folks!

So it appears I got an issue somehow similar. All my types are well generated, but when trying to resolve the mutation I get the same error as you guys mentioned.

In my configuration I have an additional resolver added, so I tried to see if I added a custom __resolveType function for my type if would work but it doesn't seem to override the existing.

So I was wondering if someone found a solution, or if you know a way to override the __resolveType function maybe this would be a way to fix this issue.

Thank you! 🙏

[nemonemi]

I have to say, I am pretty disappointed in how these tickets get addressed, let alone resolved.

[ardatan]

I have to say, I am pretty disappointed in how these tickets get addressed, let alone resolved.

Would you give a try to create a failing test in a PR or maybe get some progress towards fixing it With all the stuff you provided so far; first we need to clone your project and install it in our local, then try to reproduce the same thing by assuming the problem is not the environment(which usually is). But instead, if you use CodeSandbox or StackBlitz, we can make sure that it is not environment but the library itself. If you want to get this fixed quicker, you can create a PR with a faling test so anyone else from the community or a Guild member can use it to debug easier. The best thing in OSS projects is to develop these projects together with the users, As a maintainer of this project, I'm really sad to hear that you're disappointed but I also feel same because those GitHub issues seem like "support tickets" rather than an opportunity to take and improve the project for everyone else in the community.