selectionSet ignored for fields defined in additionalResolvers

[PlayAnyData]

Issue workflow progress

Progress of the issue based on the
Contributor Workflow

• 1. The issue provides a reproduction available on
  Github,
  Stackblitz
  or
  CodeSandbox

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

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.