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

Encapsulated resolvers to do not mesh properly #4962

Open
4 tasks
bigman73 opened this issue Dec 21, 2022 · 1 comment
Open
4 tasks

Encapsulated resolvers to do not mesh properly #4962

bigman73 opened this issue Dec 21, 2022 · 1 comment
Labels
waiting-for-answer Waiting for answer from author

Comments

@bigman73
Copy link

bigman73 commented Dec 21, 2022

Issue workflow progress

Progress of the issue based on the Contributor Workflow

Make sure to fork this template and run yarn generate in the terminal.

Please make sure Mesh package versions under package.json matches yours.

  • 2. A failing test has been provided
  • 3. A local solution has been provided
  • 4. A pull request is pending review

Describe the bug

There are two GraphQL sources, books and animals. Both have a heartbeat query that returns a String. Both services function on their own, and return a valid heartbeat.
In .meshrc.yaml the services are wrapped twice, where the outer wrapper has the same name, platform.
The schema typedefs meshes/merges as expected. When running the heartbeat on the first encapsulated service it works as expected.

The second encapsulated heartbeat fails:

{
  "errors": [
    {
      "message": "Cannot return null for non-nullable field platformQuery.pets.",
      "path": [
        "platform",
        "pets"
      ]
    }
  ],
  "data": null
}

Changing the second encapsulation to a different name, such as platform2 resolves the problem, but it's not an acceptable solution.

To Reproduce
Steps to reproduce the behavior:

sources:
  - name: BooksService
    handler:
      graphql:
        endpoint: '{env.SERVICE1_URL}'
    transforms:
      - encapsulate:
          name: library
          applyTo:
            query: true
            mutation: true
            subscription: false
      - encapsulate:
          name: platform
          applyTo:
            query: true
            mutation: true
            subscription: false
  - name: AnimalsService
    handler:
      graphql:
        endpoint: '{env.SERVICE2_URL}'
    transforms:
      - encapsulate:
          name: pets
          applyTo:
            query: true
            mutation: true
            subscription: false
      - encapsulate:
          name: platform
          applyTo:
            query: true
            mutation: true
            subscription: false

Execute query:

query {
  platform {
    pets {
      heartbeat
    }
  }
}

Expected behavior

The expected behavior is that graphql mesh meshes the resolvers of encapsulated services, since they are not colliding or conflicting. Each encapsulated service resides under a different name (e.g. library or pets).

Environment:

  • OS: MacOS 12.5.1, M1 Pro
  • "@graphql-mesh/graphql": "^0.33.5",
  • "@graphql-mesh/transform-encapsulate": "^0.4.4",
  • NodeJS: v16.18.1

Additional context

I tried to globally encapsulate the entire schema. This does work for both heartbeats but it encapsulates the additional types and resolvers, not just the source underlying schemas, so it's not a viable solution.

@ardatan
Copy link
Owner

ardatan commented Apr 3, 2023

Could you share a reproduction on CodeSandbox or StackBlitz? Thanks!

@ardatan ardatan added the waiting-for-answer Waiting for answer from author label Apr 3, 2023
This was referenced Apr 30, 2024
This was referenced May 7, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
waiting-for-answer Waiting for answer from author
Projects
None yet
Development

No branches or pull requests

2 participants