delegate: handeObject() can not handle renamed abstract types

[saerdnaer]

When I try to query an abstract type Foo, which I renamed to Chirp_Foo I get following error

TypeError: Cannot read property 'name' of undefined

from

graphql-tools/packages/delegate/src/results/handleObject.ts

Line 34 in 640de85

const typeName = isAbstractType(type) ? info.schema.getTypeMap()[object.__typename].name : type.name;

because object.__typename contains the unprocessed type name Foo from the subschema service response, where it should contain Chirp_Foo. As Foo is not in the typeMap it yields undefined which leads to the above error.

[gmac]

How is your transform structured? It would need both transformRequest and transformResult renamers...

interface Transform {
    transformSchema(originalSchema: GraphQLSchema): GraphQLSchema;
    transformRequest(originalRequest: Request): Request;
    transformResult(result: ExecutionResult): ExecutionResult;
}

[saerdnaer]

@gmac I used the default https://github.com/ardatan/graphql-tools/blob/master/packages/wrap/src/transforms/RenameTypes.ts which includes a proper transformResult() implementation

[yaacovCR]

That's annoying!

Can you post a GitHub course code sandbox reproduction?

[saerdnaer]

@yaacovCR I created a few failing tests, which also includes an example for this bug, in PR #2019 – I can also create a "GitHub course code sandbox" when you point me in to a corresponding howto.

[yaacovCR]

Dictation error, that should be fine.

[yaacovCR]

Took a quick look at #2019, does the failure of type renaming ever occur without using TransformQuery?

I think the bug is because simply using TransformQuery on delegation is not the best way to transform a query, it should usually be done as part of changing the schema, hence the WrapFields and HoistField, TransformObjectFields transforms that I have created.

Of course, see #1920, another issue I believe you raised, where the work in hoisting is not yet done.

I have been working at this time on #1958 and #1989, and then hope to return to improving HoistFields

If there is a separate problem of renaming abstract fields with RenameTypes without TransformQuery, please let me know, and narrow #2019 accordingly.

Otherwise, I think basically you are describing a bug with TransformQuery, and I would suggest in response that eventually TransformQuery should be deprecated...

Welcome also to your response/input from others, but that's just my first quick take...

[saerdnaer]

Took a quick look at #2019, does the failure of type renaming ever occur without using TransformQuery?

Yes, simply renaming types yields TypeError: Cannot read property 'name' of undefined from delegateToSchema() even without any transforms.

PR #2019 now contains the simplified version of the previous tests demonstrating this:

FAIL  packages/stitch/tests/classicStitchSchemas.test.ts (20.302 s)
  ● test delegateToSchema() with type renaming › item should work

    expect(received).toEqual(expected) // deep equality

    - Expected  - 5
    + Received  + 4

      Object {
        "data": Object {
    -     "item": Object {
    -       "__typename": "Item",
    -       "id": "123",
    -       "name": "Foo bar 42",
    -     },
    +     "item": null,
        },
    +   "errors": Array [
    +     [GraphQLError: Cannot read property 'name' of undefined],
    +   ],
      }

      120 |     );
      121 | 
    > 122 |     expect(result).toEqual({
          |                    ^
      123 |       data: {
      124 |         item: ITEM,
      125 |       },

      at Object.<anonymous> (packages/stitch/tests/classicStitchSchemas.test.ts:122:20)

[saerdnaer]

Discussion in #2019 resolved the issue: I did pass delegateToSchema the wrong subschema configuration object (which did not contain the TypeRename transform, yet).