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

Scalar variables failing validation #51

Closed
AstraLuma opened this issue Aug 29, 2019 · 6 comments
Closed

Scalar variables failing validation #51

AstraLuma opened this issue Aug 29, 2019 · 6 comments

Comments

@AstraLuma
Copy link
Contributor

When I validate these queries against this schema (via this code), I'm getting this error:

graphql.error.graphql_error.GraphQLError: Unknown type 'Int'.

/home/astraluma/code/gobuildit/gqlmod/testmod/queries.gql:15:30
14 | 
15 | query HeroComparison($first: Int = 3) {
   |                              ^
16 |   leftComparison: hero(episode: EMPIRE) {

The results of pip freeze:

astor==0.8.0
-e git+git@github.com:go-build-it/gqlmod.git@6fe690f7ffb0634f4522ded57be8f40b21205c52#egg=gqlmod
graphql-core==3.0.0a2
import-x==0.1.0
pkg-resources==0.0.0

I'm pretty new to GraphQL, but as I understand it, Int is a builtin scalar that should always be available?

@Cito
Copy link
Member

Cito commented Aug 30, 2019

Hi @astronouth7303. Graphql-core is replicating the behavior of graphql-js. Whether built-in scalars are added automatically or not has changed in the last versions of graphql-js (see graphql/graphql-js/issues/2005). The current state is that they are not added automatically, i.e. they are only included if they are used in the schema (which makes sense, if you think about it).

The actual problem here is that the query type for friendsConnection used in your query is not part of the schema, so it would not validate against that schema anyway. You need to add that type to your schema first. To construct such connection types, you can use graphql-relay-py.

@AstraLuma
Copy link
Contributor Author

Yeah, I pulled the queries from the graphql tutorial but the schema from this project's test suite. I guess they mismatch more than I think. (The starwars code is mostly for testing and toying.)

(which makes sense, if you think about it)

Ummm... I suppose? Most type systems I work with assume some number of universal builtins.

It's not clear to me what problems "automatically add builtin scalar types" creates, and that's some pretty dense stuff to wade through. I'll try again later.

  • Is this error message a sign that this query will never validate? (Can it maybe be improved in the case of builtin names?)
  • Am I missing an invocation/argument to add the builtin types on either the client and/or server side?

@Cito
Copy link
Member

Cito commented Aug 30, 2019

Yes, this query will never validate or execute until you add the friendsConnection type to your schema. And when you do this, it will then also include the Int type automatically, because it is used by the friendsConnection. You don't need to add the builtin-types manually.

@AstraLuma
Copy link
Contributor Author

I think I might do that anyway, just for UX reasons.

  • "Int not defined" => "wtf, is this thing bugged?"
  • "friendsConnection isn't found on Character" => "Oh, that's not in this schema"

Like, yeah, the query will fail to validate either way, but the first one is weird and confusing and makes you question life, while the second is sensible and useful.

@Cito
Copy link
Member

Cito commented Aug 31, 2019

GraphQL is nice in that regard: ExecutionResult.errors is a list of errors, you will get one error for the missing Int and another one for the missing friendsConnection. The missing Int error only comes first because it appears first (in line 1), while the other one appears later (in line 12).

@AstraLuma
Copy link
Contributor Author

In my application, I have to pick one error and raise that, and the error that appears first in the file is the obvious one.

(Yes, I'll add a CLI tool later that'll show all errors, but MVPs and all that.)

@Cito Cito closed this as completed Sep 14, 2019
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