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

GraphQL API files generation hangs because of improperly defined input type #379

Open
alestolfo opened this issue Jul 30, 2020 · 2 comments

Comments

@alestolfo
Copy link

Hello, I'm opening this issue as I realized that, if a input type is incorrectly defined in the schema, the generation of the GraphQL API files (elm-graphql --introspection-file Schema.json ...) can get stuck using a significant amount of computational resources, instead of aborting with an error message.

Environment

  • Elm 0.19.1
  • elm-graphql 4.0.3

Schema

This is part of the file Schema.json, automatically generated using Absinthe.

{
   "description": null,
   "enumValues": null,
   "fields": null,
   "inputFields": [
        {
        "defaultValue": null,
        "description": null,
        "name": "unit",
        "type": {
                "kind": "NON_NULL",
                "name": null,
                "ofType": {
                    "kind": "OBJECT",
                    "name": "Unit",
                     "ofType": null
                     }
                }
         }
   ],
   "interfaces": null,
   "kind": "INPUT_OBJECT",
   "name": "ProcessFlowInput",
   "possibleTypes": null
}

Expected behavior

Since an (non-INPUT) OBJECT is used as input field in the definition of an INPUT_OBJECT (wrong definition that however is allowed by Absinthe), I was expecting the GraphQL bindings generation to be aborted with an error message or some kind of feedback.

Actual behavior

GraphQL bindings generation hanging indefinitely.

@dillonkearns
Copy link
Owner

Thank you very much for the error report! I did a first pass at removing some of the infinite loop "crashes" in #459.

I'll probably do another pass at trying to remove those hangs for invalid schemas, but I'd like to address it for the remaining cases in the decoding phase by making the types more constrained. It will be a little more verbose but more precise, and then I won't have to wire through Result values all over the place but can instead Make Impossible States Impossible and validate it during decoding.

I'll report back here when I take a look at the next pass at that. It would be good to collect some test cases to make sure they're handling correctly, I might try to make a few different invalid schemas for the end to end test suite.

Thanks again for the report!

@dillonkearns
Copy link
Owner

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants