Error: Variable '$_data' cannot be non input type 'SubjectCreateInput!'

prisma

#1

I’m using the node-advanced boilerplate. When I run the boilerplate’s mutations/queries, everything works fine. My own mutations/queries run fine if I try them directly on the database. However, when I try them through the server, I get the following error:

Mutation:

mutation {
  createSubject(name: "Mathematics", slug: "mathematics", group: 5) {
    id
  }
}

Result:

{
  "data": null,
  "errors": [
    {
      "message": "Variable '$_data' cannot be non input type 'SubjectCreateInput!'. (line 1, column 19):\nmutation ($_data: SubjectCreateInput!) {\n                  ^",
      "locations": [],
      "path": [
        "createSubject"
      ]
    }
  ]
}

I think I’ve done everything required to add a new type:

  1. Added type Subject to datamodel.graphql
  2. Ran ‘prisma deploy’
  3. Created resolvers
  4. Updated schema.graphql

Here is the code: https://github.com/coniel/prisma
These are the changes I made to the boilerplate: https://github.com/coniel/prisma/commit/c8e37a0289d419fbea99f6f65fddd40219c8ae23

Am I missing something? I also tried editing my mutation resolver from

return ctx.db.mutation.createSubject({
    data: {
      name,
      slug,
      group,
    },
  },
  info
)

to

return ctx.db.mutation.createPost({
    data: {
      title: name,
      text: slug,
      isPublished: false,
      author: {
        connect: { id: userId },
      },
    },
  },
  info
)

Which created a post as expected. So I don’t think there is anything wrong with my resolver setup.


#2

Are there more debug information in the server logs?


#3
Request to http://localhost:4466/prisma/dev:
query:
mutation ($_data: SubjectCreateInput!) {
  createSubject(data: $_data) {
    id
  }
}
operationName: null
variables:
{
  "_data": {
    "name": "Mathematics",
    "slug": "mathematics",
    "group": 5
  }
}
[GraphQL error]: Message: Variable '$_data' cannot be non input type 'SubjectCreateInput!'. (line 1, column 19):
mutation ($_data: SubjectCreateInput!) {
                  ^, Location: [object Object], Path: undefined
[GraphQL error]: Message: Unknown type 'SubjectCreateInput'. Did you mean 'PostCreateInput', 'UserCreateInput', 'PostUpdateInput' or 'UserUpdateInput'? (line 1, column 19):
mutation ($_data: SubjectCreateInput!) {
                  ^, Location: [object Object], Path: undefined
[GraphQL error]: Message: Cannot query field 'createSubject' on type 'Mutation'. Did you mean 'createPost' or 'createUser'? (line 2, column 3):
  createSubject(data: $_data) {
  ^, Location: [object Object], Path: undefined
[Network error]: Error: Variable '$_data' cannot be non input type 'SubjectCreateInput!'. (line 1, column 19):
mutation ($_data: SubjectCreateInput!) {
                  ^
Error: Variable '$_data' cannot be non input type 'SubjectCreateInput!'. (line 1, column 19):
mutation ($_data: SubjectCreateInput!) {
                  ^
    at BatchedGraphQLClient.<anonymous> (/Users/oscarconiel1/Sites/coniel/prisma/node_modules/http-link-dataloader/dist/src/BatchedGraphQLClient.js:74:39)
    at step (/Users/oscarconiel1/Sites/coniel/prisma/node_modules/http-link-dataloader/dist/src/BatchedGraphQLClient.js:40:23)
    at Object.next (/Users/oscarconiel1/Sites/coniel/prisma/node_modules/http-link-dataloader/dist/src/BatchedGraphQLClient.js:21:53)
    at fulfilled (/Users/oscarconiel1/Sites/coniel/prisma/node_modules/http-link-dataloader/dist/src/BatchedGraphQLClient.js:12:58)
    at <anonymous>
    at process._tickCallback (internal/process/next_tick.js:188:7)

#4

Can you please try the two different approaches as follows?

  • rename createSubject in schema.graphql to something else, like myCreateSubject. Does that work?
  • change this line to this: # import Subject, SubjectCreateInput from "./generated/prisma.graphql". Does that work?

Thanks!


#5

Unfortunately, neither one works. Same error as before.


#6

I cannot reproduce the issue.

Here’s what I did:

  • git clone https://github.com/coniel/prisma
  • adjust the Prisma version to 1.5.3 in package.json
  • deployed to the development cluster in EU prisma-eu1
  • removed the secret and set disableAuth: true in prisma.yml (for sake of ease)

You can verify that it works by using this GraphQLServer in your src/index.js file instead:

const server = new GraphQLServer({
  typeDefs: 'src/schema.graphql',
  resolvers,
  context: req => ({
    ...req,
    db: new Prisma({
      typeDefs: 'src/generated/prisma.graphql',
      endpoint: 'https://eu1.prisma.sh/nilan-marktanner-7ea852/ibguides/dev',
      secret: 's',
      debug: true,
    }),
  }),
})

If you are still experiencing issues, you might run on an older cluster version perhaps?


#7

So it turns out it’s only my local cluster that is having issues, everything seems to work fine when I deploy it to a development cluster on Prisma Cloud as you did (apologies, I should have been more thorough in my testing and description of the issue).

Any ideas what might be causing the local cluster to have issues? I running the latest version of everything involved.

It’s not a pressing issue for me, as I’m fine using a dev cluster on Prisma Cloud over a local cluster for the time being. Would love to be able to use a local cluster in the future though.


#8

Hey @conielo, I can’t think of a reason why only the local cluster would exhibit this behaviour. When running prisma cluster list, what is the version of your local cluster?

On top of that, when opening <cluster url>/cluster (for me it’s http://localhost:4466/cluster) in your browser, and sending the following query, what is the response?

query {
  clusterInfo {
    version
    commit
  }
}

#9

I had same issue
Check out prisma.yml look at endpoint
Check out js code where you create context.db

context: req => ({
        ...req,
        db: new Prisma({
            endpoint: 'someendpoint',
        }),
    }),

These endpoints should be equal
If they equals delete stage and service from prisma.yml

In my case prisma.yml was look like this
service: 'someservice’
stage: 'somestage’
endpoint: ‘https://eu1.prisma.sh/random/default/default

prisma deploy respects service and stage from prisma.yml and deploys to https://eu1.prisma.sh/random/someservice/somestage
But new Prisma dosen’t know about service and stage and connect to https://eu1.prisma.sh/random/default/default


#10

I found this post having the same issue as original poster.
Turns out I missed the fact that my PRISMA_ENDPOINT indeed needed to be updated, so thanks for that Mikhail!


#11

My issue was that I had to use prisma deploy --force