Error "RangeError: Maximum call stack size exceeded" for some of my queries

[mnlbox]

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

---

Describe the bug
I'm getting the error bellow for some of my queries:

{
  errors: [
    RangeError: Maximum call stack size exceeded
        at computeLocations (/workspace/node_modules/.pnpm/[email protected][email protected]/node_modules/graphql-jit/src/ast.ts:946:33)
        at generateInput (/workspace/node_modules/.pnpm/[email protected][email protected]/node_modules/graphql-jit/src/variables.ts:153:21)
        at generateInput (/workspace/node_modules/.pnpm/[email protected][email protected]/node_modules/graphql-jit/src/variables.ts:376:11)
        at generateInput (/workspace/node_modules/.pnpm/[email protected][email protected]/node_modules/graphql-jit/src/variables.ts:332:13)
        at generateInput (/workspace/node_modules/.pnpm/[email protected][email protected]/node_modules/graphql-jit/src/variables.ts:376:11)
        at generateInput (/workspace/node_modules/.pnpm/[email protected][email protected]/node_modules/graphql-jit/src/variables.ts:332:13)
        at generateInput (/workspace/node_modules/.pnpm/[email protected][email protected]/node_modules/graphql-jit/src/variables.ts:376:11)
        at generateInput (/workspace/node_modules/.pnpm/[email protected][email protected]/node_modules/graphql-jit/src/variables.ts:332:13)
        at generateInput (/workspace/node_modules/.pnpm/[email protected][email protected]/node_modules/graphql-jit/src/variables.ts:376:11)
        at generateInput (/workspace/node_modules/.pnpm/[email protected][email protected]/node_modules/graphql-jit/src/variables.ts:332:13)
  ]
}

It seems it's related to graphql-jit package and maybe related to this issue: zalando-incubator/graphql-jit#81

To Reproduce Steps to reproduce the behavior:

Expected behavior
It's better if we can disable JIT with an environment variable. I see we have an unfinished PR in this regard here:
#3817

Environment:

• OS:
• @graphql-mesh/...:

@graphql-mesh/cli 0.87.14
├─┬ @graphql-mesh/config 0.97.13
│ └─┬ @graphql-mesh/runtime 0.96.11 peer
│   ├─┬ @envelop/graphql-jit 7.0.0
│   │ └── graphql-jit 0.8.2
│   └── graphql-jit 0.8.2
├─┬ @graphql-mesh/http 0.96.12
│ └─┬ @graphql-mesh/runtime 0.96.11 peer
│   ├─┬ @envelop/graphql-jit 7.0.0
│   │ └── graphql-jit 0.8.2
│   └── graphql-jit 0.8.2
└─┬ @graphql-mesh/runtime 0.96.11
  ├─┬ @envelop/graphql-jit 7.0.0
  │ └── graphql-jit 0.8.2
  └── graphql-jit 0.8.2

• NodeJS:

Additional context

[BabakScript]

@mnlbox I had the same issue for only one of my complex and nested queries. As you also marked It seems it's an issue related to the JIT package that is used in the @graphql-mesh/runtime package and started from version 0.96.3. For me, it was fixed after adding this to my package.json file, you can use it as a temp solution until the issue is fixed:

  "resolutions": {
    "@graphql-mesh/runtime": "0.96.3"
  }

[PlayAnyData]

I can confirm this is an issue. In our case providing filters as variable resulted in this issue.

As we are using npm, I fixed the version using:

  "overrides": {
    "@graphql-mesh/runtime": "0.96.3"
  }

Thanks @BabakScript for the hint!

[bcanfield]

I can confirm this is an issue. In our case providing filters as variable resulted in this issue.

As we are using npm, I fixed the version using:

  "overrides": {
    "@graphql-mesh/runtime": "0.96.3"
  }

Thanks @BabakScript for the hint!

This worked for us!!!! Thank you.

[mnlbox]

@ardatan it's still exists on the latest version of mesh but it works with the hack suggested by BabakScript (Thanks @BabakScript 🎉 )
I couldn't create the reproduction repo for it because it's just happening for some data sources and only some specific queries but I couldn't find what especial parts in the query, break it.
Is the issue clear from yous side or do we need a reproduction repo for it? (I'm asking because it looks it's happen for others too)
Is there any way to disable JIT in graphql-mesh?

[Urigo]

Thanks everyone for the report!

can someone create a runnable reproduction of the issue?

Just to advance from stage 0 forward according to our new Contribution Guide and issue flow.

Thank you and sorry that this comment is not a complete solution (yet).

[PlayAnyData]

For us the problem was related to queries like this:
query getObjectByKeys($filter: InputTypeKeys!) { objectList(instance: "123", limit: 10, filter: $filter) { items { id } totalCount limit } }

with:
{ "filter": { "myKey": { "in": [ "301" ] }, "inactive": { "equals": false } } }

leading to:
{ "errors": [ { "message": "Maximum call stack size exceeded" } ] }

whereas this kind of query (filters inlined):
query getObjectByKeys { objectList(instance: "123", limit: 10, filter: { myKey: { equals: "301" }, inactive: { equals: false } }) { items { id } totalCount limit } }

ran just fine. Not sure, if I can provide a minimum working example soon, as our structure is very complex. But I hope this helps.

[PlayAnyData]

@Urigo
Finally, I was able to create a reproduction sample. You can find it in this branch: https://github.com/PlayAnyData/mesh-error-duplicate/tree/reproduce/6107

I guess it is related to the combination of the schema, because if you comment the second schema in the sources definition it is working fine.

I have written down detailed reproduction information in the README in the repo.

In case of any questions do not hesitate to contact me.

[BabakScript]

@Urigo @ardatan We are still using "@graphql-mesh/runtime": "0.96.3" as I mentioned above as a short-term workaround to prevent this issue but as we got a high-level security issue reported because of the 0.96.3 version of the runtime package from last week, I just wrote here to see if there is any better short-term solution available to fix this issue? Or maybe after the sample repo from @PlayAnyData, we can solve the issue completely.

You can see the security issue reported by Mend here:
https://www.mend.io/vulnerability-database/WS-2023-0330

[champikasam]

I'm also facing this issue and currently using the workaround suggested by @BabakScript (thanks for the workaround @BabakScript !). I'll follow this thread to know when a better solution becomes available.

[mnlbox]

Guys, is it still safe to use 0.96.3 version of runtime package?
Is there any other safe short-term workaround to prevent this bug on mesh?

[BabakScript]

Thanks @ardatan for the fix. 👍
I can confirm the new version is working well without any issues with our Graph.