Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Request variables with circular dependency #81

Open
joooika opened this issue May 15, 2020 · 9 comments · May be fixed by #82
Open

Request variables with circular dependency #81

joooika opened this issue May 15, 2020 · 9 comments · May be fixed by #82
Assignees
Labels
bug Something isn't working

Comments

@joooika
Copy link

joooika commented May 15, 2020

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
Copy link
Collaborator

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

@boopathi boopathi self-assigned this May 16, 2020
@boopathi boopathi added the bug Something isn't working label May 17, 2020
@joooika
Copy link
Author

joooika commented May 18, 2020

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

@boopathi
Copy link
Member

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
Copy link
Author

joooika commented Jun 15, 2020

@boopathi any update?

@edmundyipll
Copy link

@boopathi Hi,

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

@tonyfromundefined
Copy link

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
Copy link

olup commented Jan 14, 2021

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

@olup
Copy link

olup commented Jan 26, 2021

Any plan on merging the referenced PR ?

@jgoux
Copy link

jgoux commented Jan 19, 2022

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

7 participants