ardatan / graphql-mesh

🕸️ GraphQL Federation Framework for any API services such as REST, OpenAPI, Swagger, SOAP, gRPC and more...
https://the-guild.dev/graphql/mesh
MIT License
3.3k stars 347 forks source link

selectionSet ignored for fields defined in additionalResolvers #7423

Open PlayAnyData opened 3 months ago

PlayAnyData commented 3 months ago

Issue workflow progress

Progress of the issue based on the Contributor Workflow

Reproduction info in README in provided link


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"

Additional context

Was working fine in previous versions.

ardatan commented 3 months ago

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

PlayAnyData commented 3 months ago

@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 commented 1 month ago

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

PlayAnyData commented 2 weeks ago

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