dillonkearns / elm-graphql

Autogenerate type-safe GraphQL queries in Elm.
https://package.elm-lang.org/packages/dillonkearns/elm-graphql/latest
BSD 3-Clause "New" or "Revised" License
778 stars 107 forks source link

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

Open alestolfo opened 4 years ago

alestolfo commented 4 years ago

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

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 commented 3 years ago

Thank you very much for the error report! I did a first pass at removing some of the infinite loop "crashes" in https://github.com/dillonkearns/elm-graphql/pull/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 commented 3 years ago

I released the changes from #459 in this NPM release https://github.com/dillonkearns/elm-graphql/blob/master/CHANGELOG-NPM-PACKAGE.md#420---2021-02-05.