Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[BUG (wrap)]: applying multiple rename transforms breaks requests #1795

Closed
jakeblaxon opened this issue Jul 17, 2020 · 11 comments
Closed

[BUG (wrap)]: applying multiple rename transforms breaks requests #1795

jakeblaxon opened this issue Jul 17, 2020 · 11 comments

Comments

@jakeblaxon
Copy link
Contributor

jakeblaxon commented Jul 17, 2020

When applying multiple RenameX transforms in a row that touch the same node types, the schema transform succeeds, but the request/response transforms seem to break.

For example, if I try to do the following,

const newSchema = wrapSchema(originalSchema, [
  new RenameObjectFields((_, fieldName) => "prefix1_" + fieldName),
  new RenameObjectFields((_, fieldName) => "prefix2_" + fieldName),
]);

newSchema will successfully be created, but the result returned for any query that I make to it is always null.

A minimal reproduction for this issue can be found here: https://github.com/jakeblaxon/graphql-tools-1795-reproduction

@jakeblaxon jakeblaxon changed the title [wrap]: applying multiple rename transforms breaks requests [BUG (wrap)]: applying multiple rename transforms breaks requests Jul 17, 2020
@yaacovCR
Copy link
Collaborator

Hmmm. This requires investigation, as off the top of my head I suppose this should work.

However, it seems like you could simply combine the two transforms... Is there a use case you were trying to solve?

@jakeblaxon
Copy link
Contributor Author

I discovered this issue when working with graphql-mesh. We have the option to apply multiple different types of transforms declaratively in a yaml file, such as adding a prefix and changing the naming convention. However, if I try to apply these two together to the same source then this issue appears. It’s subtle because the schema does get created successfully. It seems like there’s something wrong with how the requests are transformed.

@yaacovCR
Copy link
Collaborator

Sigh, got it, will investigate. If you can intercept the delegated requests and results, that would help

@jakeblaxon
Copy link
Contributor Author

Thank you! Here's some info that may help. For the graphql-mesh defined by:

sources:
  - name: container
    handler:
      graphql:
        endpoint: http://localhost:8080
    transforms:
      - prefix:
          includeRootOperations: true
          value: prefix1
      - prefix:
          includeRootOperations: true
          value: prefix2

and for the query:

{
  prefix2prefix1test
}

I received the following request to my source server (from the mesh server):

{
  prefix1test: test
}

My source server responded with:

{
  "prefix1test": "hello, world"
}

but my mesh server responded with:

{
  "error": {
    "errors": [
      {
        "message": "Cannot return null for non-nullable field Query.prefix2prefix1test.",
        "locations": [
          {
            "line": 2,
            "column": 3
          }
        ],
        "path": [
          "prefix2prefix1test"
        ]
      }
    ],
    "data": null
  }
}

Looking at this, it seems like the request actually is getting transformed correctly, but the response transforming prefix1test into prefix2prefix1test isn't working.

@yaacovCR
Copy link
Collaborator

This code is blowing away aliases, which is causing the problem.

yaacovCR added a commit that referenced this issue Jul 19, 2020
#1795 and likely additional aliasing issues
@yaacovCR
Copy link
Collaborator

The latest changes of #1799 are available as alpha in npm: 6.0.15-alpha-09a9afe2.0

Quickly update your package.json by running:

npx match-version @graphql-tools 6.0.15-alpha-09a9afe2.0

Thanks for reporting!

@yaacovCR yaacovCR added bug waiting-for-release Fixed/resolved, and waiting for the next stable release labels Jul 19, 2020
@jakeblaxon
Copy link
Contributor Author

Thank you @yaacovCR for taking care of this so quickly!!

@ardatan ardatan reopened this Jul 19, 2020
@ardatan
Copy link
Owner

ardatan commented Jul 19, 2020

Let's keep it open until it gets released

@jakeblaxon
Copy link
Contributor Author

Sounds good. @ardatan I'll let you close it when you're ready.

@ardatan
Copy link
Owner

ardatan commented Sep 1, 2020

Available in 6.2.0!

@ardatan ardatan closed this as completed Sep 1, 2020
@yaacovCR yaacovCR removed bug waiting-for-release Fixed/resolved, and waiting for the next stable release labels Oct 25, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants