Request variables with circular dependency

[joooika]

Hi,

I encountered this issue when making a create request for entity A that has a circular reference with B. Schema definition is implemented with type-graphql roughly like this.

@ObjectType()
@InputType('FooInput')
class Foo {
    @Field(() => Number)
    id: number;
    @Field(() => Bar, {nullable: true})
    bar: Bar;
}

@ObjectType()
@InputType('BarInput')
class Bar {
    @Field(() => Number)
    id: number;
    @Field(() => Foo, {nullable: true})
    foo: Foo;
}

@Resolver(Foo)
class FooResolver {
    @Mutation()
    addFoo(@Arg('foo') foo: Foo): string {
        return 'ok';
    }
}

Now if I try to send a query

mutation AddFoo($foo: FooInput!){
    addFoo(foo: $foo)
}

with variables

{
  "foo": {
    "id": 1,
    "bar": null
  }
}

the query execution gets stuck in a recursive loop during compileQuery call or more specifically in generateInput function. Apparently when going through the request variables in if (isInputType(varType)) block generating another call to itself and this goes on until out of memory error.

I'm using apollo-server with custom executor like described in the examples. Similar issues do not occur with default apollo-server config or by running the query with with graphql-js execute.

new ApolloServer({
    executor: ({ source }) => {
      const compiled = compileQuery(schema, parse(source)); // <-- never returns from here
      // ...
    }
});

[ruiaraujo]

@joooika interesting, if you could provide a small repo with the reproduction I could probably fix it quickly.

[joooika]

@ruiaraujo @boopathi thanks for reply. Noticed the PR. Still need example for this?

[boopathi]

Still need example for this?

@joooika no. The example in the issue description is good. You can take a look at the test cases in that PR - It covers the recursive types, as well as mutually recursive types (as in your example). In case I missed something, please feel free to comment.

[joooika]

@boopathi any update?

[edmundyipll]

@boopathi Hi,

I have encountered the same issue. Is there any update? Thanks a lot.

[tonyfromundefined]

I met the same problem. By removing the Recursive Input Type, I gave up the beauty of the schema and took performance, but I want to design the schema beautifully again.

[olup]

I just hit it too today.. Too bad JIT sounded like a huge improvment

[olup]

Any plan on merging the referenced PR ?

[jgoux]

Hello all,

We are having the same issue using graphql-mesh, which rely on graphql-jit : ardatan/graphql-mesh#3493

We provided a small reproduction in the issue I linked.

I think to avoid this issue we could either set a maximum call stack count or record the types encountered?

This is blocking anyone trying to use graphql-mesh in front of Hasura, as Hasura generates recursive types by default in their filters inputs.