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

selectionSet ignored for fields defined in additionalResolvers #7423

Open
2 of 4 tasks
PlayAnyData opened this issue Jul 31, 2024 · 4 comments
Open
2 of 4 tasks

selectionSet ignored for fields defined in additionalResolvers #7423

PlayAnyData opened this issue Jul 31, 2024 · 4 comments

Comments

@PlayAnyData
Copy link
Contributor

PlayAnyData commented Jul 31, 2024

Issue workflow progress

Progress of the issue based on the
Contributor Workflow

  • 1. The issue provides a reproduction available on
    Github

Reproduction info in README in provided link

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

Describe the bug

We have defined additionalResolvers in the appropriate file such as:
Header_ID_V5_V4: { deprecated: mapFromField('original'), },

This field is defined in the schema as:

@ObjectType()
export class Header_ID_V5_V4 {
[...] //left out some fields 
  @Field(() => String, {
    nullable: false,
  })
  original!: string;

  @Field(() => String, {
    deprecationReason: "('use original instead')",
    nullable: true,
  })
  deprecated!: string | null;
}

Where mapFromField is defined as (effectively it is just a pushdown of an additional selection, as a field has been deprecated and we have changed the naming, therefore we do the mapping in the gateway, as it was the easiest way to solve this generically):

/**
 * Maps a field to another 1:1
 * @param originalFieldName the original field's name
 * @returns the field's value
 */
export function mapFromField(
  originalFieldName: string
) {
  return {
    selectionSet: `
    {
      ${originalFieldName}
    }`,
    resolve(root) {
      return root[originalFieldName];
    },
  };
}

However, running this code, the result is not as expected as deprecated is not filled. This is due to original not being pushed to the subgraph, as expected. A check in onFetch shows that the field is not part of info.fieldNodes, which I would have expected. In the subgraph, the selectionSet also does not define original but instead only deprecated.

To Reproduce Steps to reproduce the behavior:

Create a simple selectionSet on oneField with a definition as above and try to map it. It will not work :-(

Expected behavior

In previous versions, e.g. this resolved correctly. I would have expected original being send to the subgraph.

Environment:

We are using the following versions:

"@graphql-mesh/cli": "^0.92.5",
    "@graphql-mesh/graphql": "^0.99.5",
    "@graphql-mesh/http": "^0.100.5",
    "@graphql-mesh/plugin-hive": "^0.99.5",
    "@graphql-mesh/transform-filter-schema": "^0.99.6",
    "@graphql-mesh/transform-rename": "^0.99.5"
  • NodeJS: v18

Additional context

Was working fine in previous versions.

@ardatan
Copy link
Owner

ardatan commented Aug 6, 2024

Thanks for the issue!
Could you create a reproduction? So we can reproduce it as well!

@PlayAnyData
Copy link
Contributor Author

PlayAnyData commented Aug 8, 2024

@ardatan Sure, you can find it in this branch. https://github.com/PlayAnyData/mesh-error-duplicate/tree/reproduce/7423 I have added further information to readme on how to reproduce.

Thanks for having a look at it.

@enan69500
Copy link

Hi @ardatan , have you reproduce this issue ? No fix is planned ?

@PlayAnyData
Copy link
Contributor Author

I have just updated the repo with latest 0.* version and the issue still exists. Any chances of fixing this?

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