thread 'rustc' has overflowed its stack

[robot-head]

I have a schema generated by a hasura instance that is causing the rust compiler to panic.

thread 'rustc' has overflowed its stack

Schema and query causing the issue:
rustc_panic.zip

I had some code working successfully with a previous schema, but I added some tables and now I'm getting a stack overflow.

I'm wondering if there's some recursive relationships in my schema that are causing issues, or just the size of the schema itself (hasura generates a ton of schema)... mine is currently 732kb of JSON

[tomhoule]

Thanks for reporting the bug. I think it has more to do with the query, because we don't recurse much when parsing the schema, as far as I remember. Could you share a schema/query combination that reproduces the crash?

[d0nutptr]

Hey @tomhoule !

I'm also encountering this issue.

The following should reproduce the issue for you.

mutation AddANewOrganization($input: AddOrganizationInput!) {
    addOrganization(input: [$input]) {
        numUids
    }
}

input AddOrganizationInput {
    elements: ElementRef
}

input ElementRef {
    org: OrganizationRef
    parent_element: ElementRef
}

input OrganizationRef {
    parent_org: OrganizationRef
    widgets: ResourceRef
}

input ResourceRef {
    id: ID
    element: ElementRef
}

[samuela]

See also rust-lang/rust#75798 for another reproduction of this.

[EverlastingBugstopper]

I'm running into this error as well here

[JakeDawkins]

I've built a simple runnable reproduction in this repo. If you cargo run that repo, it will fail.

This is what I've figured out so far:

type Query {
  test: Boolean
}

type Mutation {
  run(input: A): Boolean
}

input A {
  b: B
}

input B {
  c: C # if you comment out this line, it will build
  b: B
}

input C {
  c: C
}

Given this Schema, if you try to compile the run mutation, it will fail. The input types of this schema reference each other like so:

A -> B -> C -> C: This is NOT okay, and will fail. But...

A -> B -> B will build without issue. It seems to be the self-referencing input type C, but only past a certain depth, which I don't understand fully.

I hope someone has the spare time to take a look, since this is inherently blocking for working with graphql introspection results as input types, and may require us to fork eventually if this can't get resolved

[tomhoule]

Does this happen on master, or only on the released version? There is a large refactoring of query processing that hasn't been released yet.

[EverlastingBugstopper]

it seems to work with the master branch!!

[JulesGuesnon]

Hey there !

First, thanks for this awesome library !

I happened to face this issue too. I'm using prisma and it generates recursive types for filters.
Basically, it looks like this:

type Query {
    hello(filter: Filter): Hello
}

input Filter {
    AND: [Filter],
    OR: [Filter],
    field1: String,
   field2: Int
}

Which leads to Filter -> Filter -> Filter -> Filter -> ...
And I guess this why I get a stack overflow.

Did someone already have the same issue ? And is there a workaround or maybe something planned for recursive types ?

Btw, I tried on 0.9.0 and master as well.

[tomhoule]

There is nothing planned because nobody has capacity to work on this crate at the time. I would happily review a PR, though.

[JulesGuesnon]

Thanks for your answer !

I dived in, and I'm not sure anymore if it's a recursion error.
The overflow happens here:

graphql_client_codegen/codegen/inputs.rs

quote! {
    #variable_derives
     pub struct #struct_name {
          #(#fields,)*
      }
}

I have also tried naively boxing the generated modules thinking that this would remove the module from the stack and free up space for the next modules, but this does not work.

graphql_client_codegen/lib.rs

for operation in &operations {
        let generated = Box::new(
            generated_module::GeneratedModule {
                query_string: query_string.as_str(),
                schema: &schema,
                resolved_query: &query,
                operation: &operation.1.name,
                options: &options,
            }
            .to_token_stream()?,
        );
        modules.push(generated);
}

I'll keep looking for a fix, and eventually open a PR if I find one.

[tomhoule]

I'll help any way I can, thanks for investigating this :)

Btw, this is not completely related, but I work at prisma —_are you trying to talk to the query engine directly over the graphql-like internal protocol?

[JulesGuesnon]

Well, what a coincidence ! But no, I'm trying to consume the exposed API made with Prisma + Nexus prisma plugin.

I had a look to quote! to see if there's some limitations, but I couldn't find some so I'll keep looking.
For now, I still have a few more ideas to test with the Map that contains the Input struct that is converted by the quote! so I hope it'll work.

[noverby]

With my MR schema exports from Hasura finally work!