Naming convention and rename transforms make requests fail for nested object in the input variables with gRPC sources

[EduardValentin]

Issue workflow progress

Progress of the issue based on the
Contributor Workflow

• 1. The issue provides a reproduction available on
  Stackblitz

I could not make the servers connect to eachother on stackblitz but make sure to clone the repository and run npm install on the root folder and again in the graphql-mesh folder.
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

Using grpc sources that generate the inner schemas with full package segments unified by an underscore, for example: com_example_user_v1_user_UserProto. And, when using the naming convention transform in wrap mode that changes those namings from snake case to camel case, all the requests to a grpc service method that are using variables, and those variables are objects with a nested object inside the variable properties will fail with the reason that the nested property naming provided in camel case, is wrong and it expects the snake case variant.

To Reproduce Steps to reproduce the behavior:

• Clone the repository available on this Github Link or on Stackblitz (the current setup doesn't work on Stackblitz. Mesh can't connect to the nodejs server there, so that's why I suggest to clone the repo)
• Install the dependencies on both the node.js server and the graphql-mesh directory.
• Start the node server by running node index.js in the root folder.
• Start graphql-mesh by running npm run dev in the graphql-mesh directory
• Go into the playground and make a request using variables like the following:

mutation Example($input: V1GraphqlRequestInput) {
  apiV1GraphqlExampleServiceCreateExample(input: $input) {
    fieldTwo
    nested {
      nestedFieldTwo
      nestedFieldOne
    }
  }
}

And provide the following variables in the bottom box, next to the Headers tab:

{
  "input":{
    "fieldOne": "a",
    "fieldTwo": "b",
    "nested": {
      "nestedFieldOne": "23",
      "nestedFieldTwo": "xxx"
    }
  }
}

Expected behavior

The request should echo back the input object. But, instead, an error is returned:

{
  "errors": [
    {
      "message": "Variable \"$input\" got invalid value { nestedFieldOne: \"23\", nestedFieldTwo: \"xxx\" } at \"input.nested\"; Field \"nestedFieldOne\" is not defined by type \"com_example_v1_graphql_NestedObject_Input\". Did you mean \"nested_field_one\" or \"nested_field_two\"?"
    },
    {
      "message": "Variable \"$input\" got invalid value { nestedFieldOne: \"23\", nestedFieldTwo: \"xxx\" } at \"input.nested\"; Field \"nestedFieldTwo\" is not defined by type \"com_example_v1_graphql_NestedObject_Input\". Did you mean \"nested_field_two\" or \"nested_field_one\"?"
    },
    {
      "message": "Variable \"$input\" got invalid value { fieldOne: \"a\", fieldTwo: \"b\", nested: { nestedFieldOne: \"23\", nestedFieldTwo: \"xxx\" } }; Field \"fieldOne\" is not defined by type \"com_example_v1_graphql_Request_Input\". Did you mean \"field_one\" or \"field_two\"?"
    },
    {
      "message": "Variable \"$input\" got invalid value { fieldOne: \"a\", fieldTwo: \"b\", nested: { nestedFieldOne: \"23\", nestedFieldTwo: \"xxx\" } }; Field \"fieldTwo\" is not defined by type \"com_example_v1_graphql_Request_Input\". Did you mean \"field_two\" or \"field_one\"?"
    }
  ]
}

Environment:

• OS: macOS 13.3.1 (it also happens in our Kubernetes cluster)
• NodeJS: v16.16.0
• Using the following dependencies:

"@graphql-mesh/cli": "^0.82.13",
"@graphql-mesh/grpc": "^0.29.2",
"@graphql-mesh/transform-naming-convention": "^0.13.15",
"@graphql-mesh/transform-rename": "^0.14.15",
"dotenv": "^16.0.3",
"graphql": "^16.6.0"

Additional context

The problem seems to happen whenever I use variables with nested fields in them. If there is only one level of nesting in the variables, the request works. I suppose the other transforms that apply regex won't work as well