GraphQL permits null fields on mutation

I’m not new to Dgraph, but I’m new to GraphQL, so there is likely something simple I don’t understand. The gist of my question is why do the auto-generated mutations not enforce the presence of fields marked non-null on types.

The details:

I was just re-evaluating using GraphQL with Dgraph, so I started with a simple GraphQL schema using Dgraph cloud:

type Thing {
    id: ID!
    name: String!
    description: String!
}

Per the schema download that is available after deploying this change, there is an addThing mutation and AddThingInput input that are automatically generated. The input has all of the non-null fields on the object marked as non-null on the input:

type Mutation {
	addThing(input: [AddThingInput!]!): AddThingPayload
	...
}
input AddThingInput {
	name: String!
	description: String!
}

My guess was that this situation would enforce all non-null fields to be present on a mutation using addThing, and would enforce their presence on the result as well according to the GraphQL docs (null/error propagation). However, I’m able to add a Thing without the description field set:

mutation MyMutation {
  addThing(input: {name: "asdf"}) {
    numUids
  }
}

This completes without issue. But then when I try to query the object back out:

query MyQuery {
  queryThing(first: 10) {
    description
    id
    name
  }
}

I get an error:

Non-nullable field ‘description’ (type String!) was not present in result from Dgraph. GraphQL error propagation triggered.

I understand the error and why it is returned on the query. My question is why is AddThingInput not enforcing all fields be present and not null during the mutation?

Like it said, it is likely some misunderstanding on my part, but it was weird to add data and immediately try to query it only to get an error.

1 Like

You’re right. If the description is required, an error is supposed to be thrown if you create the thing without a description.

But that error is something that I see when the schema changes and I still have data that was valid according to an older schema.

This error could have resulted if you had said the description was optional, then created the data, then made the description required, then queried the data.

Thanks for confirmation.

I just deleted the backend, created a new one, added the Thing schema as described in my first post, and then started adding objects with only an ID:

mutation MyMutation {
  addThing(input: {})
}

I don’t get any errors while doing this. When I query back just the id field, I can see the new objects. If I add in the other fields to the query, I get the error as described.

Weird.

This sounds like a bug and should be reported.

1 Like

This is duplicated of No input field null validation on non nullable fields - #9 by noisykeyboard

Also, I’m not sure if there is validation in mutation inputs. I thought it was param-related only. Need to check.

Closing, any new input for this topic let’s do it there.

Cheers.