selectionSet ignored for fields defined in additionalResolvers

[PlayAnyData]

Issue workflow progress

Progress of the issue based on the Contributor Workflow

• [x] 1. The issue provides a reproduction available on Github

Reproduction info in README in provided link

• [x] 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]

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

[PlayAnyData]

@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]

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

[PlayAnyData]

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

[PlayAnyData]

Could be related to: https://github.com/ardatan/graphql-mesh/issues/7996 (so looks like this might be a problem in v1 as well?)

Could you give me a pointer what might go wron, such that I could try fixing it on my own. So far, I do not have a clue where to start.

[PlayAnyData]

Hi @ardatan, any ideas?

[PlayAnyData]

We have upgraded to v1 and this does not seem to be a problem there, so I will close it here.