Infinite recursions when using Query variables with recursives types

[avallete]

Describe the bug
The two same queries, one with a parameter statically put in it, the other one with the same parameters passed as "Query Variables" result in two different behavior.

The first one is working fine, the second one ends up in a "Maximum call stack size exceeded" error.

To Reproduce
I don't have a codesandbox here, but investigating the issue, I narrowed down a MRE schema.graphql with a query who would trigger the issue:

Given the following schema.graphql schema definition:

"""
Boolean expression to compare columns of type "uuid". All fields are combined with logical 'AND'.
"""
type uuid_comparison_exp {
  _eq: String
  _neq: String
}

schema {
  query: query_root
}

type query_root {
  projects: [projects!]!
}

type tasks {
  id: String!
}

"""
Boolean expression to filter rows from the table "tasks". All fields are combined with a logical 'AND'.
"""
type tasks_bool_exp {
  _or: [tasks_bool_exp!]
  id: uuid_comparison_exp
}

type projects {
  """ An array relationship """
  id: String!
  tasks(where: tasks_bool_exp): [tasks!]!
}

This following graphql query will work:

query ProjectTasksList_data {
  projects {
    tasks(where: {id: {_eq: "357fb463-97aa-40b9-8ef3-f8ec1dc88f88"}}) {
      id
      __typename
    }
    __typename
  }
}

---

The following graphql query will result in an Maximum call stack error:

query ProjectTasksList_data($filter: tasks_bool_exp) {
  projects {
    tasks(where: $filter) {
      id
      __typename
    }
    __typename
  }
}

Query variables definition:

{
    "filter": {
        "id": {
            "_eq": "357fb463-97aa-40b9-8ef3-f8ec1dc88f88"
        }
    }
}

---

Using .meshrc to transform the graphql schema like so will solve the "maximum called stack" error on the second request.

sources:
  - name: Hasura
    handler:
      graphql:
        endpoint: "<myendpoint>"
    transforms:
      - filterSchema:
          filters:
            - tasks_bool_exp.{id}
 ...

Here, as you can see, I simply filter out the recursive "_or" parameter from the "task_bool_exp" type. Doing so allow the query to execute properly. Leading me to believe the issue is probably related to the way we handle (JSONification) query variables arguments.

Expected behavior
The two queries should return the same non-errored results.

Environment:

• OS: OSX, Windows, Linux
• "@graphql-mesh/cli": "0.48.0",
• "@graphql-mesh/graphql": "0.20.12",
• "@graphql-mesh/transform-filter-schema": "0.14.8",
• NodeJS: v14.18.2

Additional context
Possibly related #1751

As a little more context, the API I'm meshing with is generated by Hasura so the filtering "recursive" types are automatically generated I cannot really get rid of them.

The "DEBUG" mode didn't bring a lot of intel, but there are the logs of a query failing because of this issue:

After some more digging and CPU profiling, I think I've been able to pin down the root the the issue, it comes from the graphql-jit dependency and the way they handle variables:

This is the CPU profiling I used to get to this conclusion:

Looking at graphql-jit repository it seems that an issue related is already opened on this subject:

zalando-incubator/graphql-jit#81

[rohinz]

Hey @Urigo, this is a really blocking issue. Do you have any plans how to handle this? Making graphql-jit optional would be an option.

[ardatan]

#3817 (comment)
Could you try DISABLE_JIT=1 env var with these canary versions?

[ardatan]

JIT isn't used anymore so the issue shouldn't be happening now :)

[mnlbox]

@ardatan maybe related:
#6107