0.7 source-graphql isn't accepting type [Int] query arguments

[narration-sd]

Description

I'm using Craft CMS's new internal GraphQL in context of adding a very nice ability for Gridsome. This was working fine in Gridsome 0.6 with the prior method of accessing external GraphqL servers.

Now, when I define a (necessary) page query of form:

   query someQuery (id: [Int], url: [String]) { 
    craftgql {
     entries (id: $id, url: $url) {
       ...
      }
    }
  }

• the [String] argument is accepted and works fine, if it's there alone
• the [Int] argument, however, fails hard when used in entries(), a valid entity in the Schema to query
• with gridsome build, I get an error like:

Error: Variable "$id" expected value of type "[Int]" which cannot be used as an input type.
GraphQL request:84:24
83 |
84 | query CardzrNoID ($id: Int, $uri: [String]) {

• There's a note in the graphql js source that this should be caught in schema validation, but perhaps you only do that on gridsome develop, where I see:

Module build failed (from ./node_modules/gridsome/lib/plugins/vue-components/lib/loaders/page-query.js):
Error: Unknown type "[Int]". Did you mean "Int"?

• And no, I don't mean "Int". id in this case is defined in the Craft Schema as [Int], not Int. If you wonder, List types also accept single values, so that covers "Int" but anyway that's not at issue here.

Summary: some how Gridsome's plugin seems not to pick up that [Int] is a List type, so that it's not allowed per the js graphql definition.mjs code as an Input Type. That's the root of the error reported in this issue.

I realize this sounds at first like something to do with Craft's internal GraphQL server's Schema defs, but the same schema and (real) query works fine (with the [Int]) when I access directly through the service inside Craft, or through Gatsby as a page query, or indeed when I exercise it point-blank using Insomnia.

I've also looked at the GraphQL schema-defining source in Craft, which uses webonyx underneath, and ìd` does seem to be defined as List of Int type.

Steps to reproduce

• make your own query on some server and table of the form above, with an [Int] array query argument defined for a field that accepts array of ints. No need to actually set the query variable, or you can set it to null as either is acceptable since it's not defined non-null.
• hmm. You can run your query against your own server, and see if you get the error. I'm just realizing that if you don't, I'm going to need to set up a publicly accessible Craft with GraphQL server to test against so you can see it.
• or, if there's a way I could conveniently dump out the resolved schema from a page source in Gridsome, let me know, and happy to do that, should you need it...

Expected result

Such a query should work fine, as it does against the (very different) CraftQL plugin. And no, this is not an alternative for many going forward.

Actual result

Error as above.

Environment

Libs:
- gridsome version: v0.7.4
- @gridsome/cli version: v0.2.4


Browser:
- [ X] Chrome (desktop) version latest

 
For Tooling issues:
- Node version: v12.6.0
- Platform:  =Win10 extreme up-to-date

[narration-sd]

Ok, I did one more obvious thing, after checking Craft's GraphQL to assure it's registering id as a proper [Int] List of Ints.

I ran the real query in Gridsome dev's explore Playground -- and it is accepted there with the $id: [Int] definition and use in entries() present. No error, and you get result records..

However, it does not obey an id query variable, { "id": 6 } at all, nor an array either -- anything in id is ignored, and you just get all the records, unrestricted

But, if you put id: 6 or id: [6,7] in the entries() arguments as a constant, it's obeyed, records are restricted properly.

This same test of using a constant works fine in the page query also.

Thus, I think we can say:

• probably, Craft's Gql is operating properly, giving a proper schema, as Playground accepts the entire form using id and $id, and indeed the problem page query accepts id: as an entries query argument.
• the problem seems to center around query variables, then.
• in page queries, the entries variable id gives the errors I showed above -- unless it is given a constant instead of an entry variable definition in the query
• in Playground, there's no error on having the entry variable definition for id, but this is ignored in terms of actually connecting values to it. By contrast the [String] uri variable does connect Entry Variable values, works fine.

I suspect this gives you enough information without having to have a Craft Gql server available, but let me know. I have one more thing to try out here for bounding this, but not tonight; it's late.

[narration-sd]

Ok, I figured a faster way to do the completing test, so it's done this evening after all. I've hooked up Gridsome 0.7.4 with a CraftQL plugin GraphQL server, using the same source-graphql plugin.

Result: very simple. The same exact fail happens. We've a year's experience with CraftQL, so I think its schema is quite trustworthy.

I also again got a working page query by taking back out the query variable id as [Int] definition and use.

Thus I think it's pretty clear the problem isn't in these two GraphQL servers, and thus you should be able to demonstrate it with your own GraphQL server, by arranging an [Int] query variable.

Cheers...!

[hjvedvik]

Thanks for a detailed issue! The problem is that Gridsome has a temporary solution for transforming $id: String! to $id: ID! in queries and show a deprecation notice. I'll make it only transform variables used on types which inherit the Node interface and publish a new version later today :)

[narration-sd]

Takk for det! I had spotted that transforming in the code, but didn't see right away how it could cause the error I tracked down....but this morning, likely I do :)

Looks like you already have the update in; sorry it took so much to build around your preliminary Type fix. But I quite applaud what seems the original purpose, that you are making things easy for people in the 'corners' of using Gridsome.

That's the kind of thoughtful design I particularly stand up for. In fact, this thing I'm building has a 'robot' in it to do that kind of help for situations that can arise which can't be coded around, an interesting thing to work out, but fun even for me to use.

No rush at all on the version, and no doubt there are other things to get into that. But when it comes, will give it a spin for sure.

Thanks again, Hans-Jørgen 🚣‍♂️

[narration-sd]

Ok! Just got 0.7.5, thanks, and your fix is working, for Gridsome itself. Queries with [Ints] for id are accepted, and indeed limit the result properly, within my built app. Which by the way, is demonstrating Live Previews for Gridsome via a plugin in Craft. Not released yet, as the Gridsome part is reaching its final architecture.

I'll put a screenshot below, showing that for Gridsome's very nice explore/Playground, things don't appear to be quite connected yet. There, id is accepted as [Int], in the query, but isn't obeyed when setting a query variable for it. You can see the message I get when hovering, flagged by the red bar, and some data also with ids that don't match it -- the one that does is off-screen.

Playground is not a priority here, as I can also use Insomnia, so as you can fold it in would be fine.

Quite appreciated to have gotten so rapidly what does let me proceed, Hans-Jørgen. and I always feel comfortable to return to working with Gridsome.

[hjvedvik]

Bare hyggelig! We try not to break too much in the minor releases and show a deprecation warning before removing if possible :)

Glad the variables work for you now. But I'm not sure what's going on in the GraphQL Playground. It might be a bug with the package Gridsome use for it.

Looking forward to checking out that Craft plugin with Live Previews!