Bug: Execution Failed Because Some Variables are Defined But Not Used

Issues GraphQL
, ,
1

Report a GraphQL Bug

What edition and version of Dgraph are you using?

Cloud DGraph

Dgraph Version 
$ v21.03.0-58-g17f52bc78

Have you tried reproducing the issue with the latest release?

Yup, using it.

Steps to reproduce the issue (paste the query/schema if possible)

In my standard Tasks Test App, I add some todos, then try to delete them:

Schema:

type Task  @withSubscription @auth(query: { rule: "query($EMAIL: String!) { queryTask { user(filter: { email: { eq: $EMAIL } }) { email } id } }"}) {
	id: ID!
	title: String! @search(by:[fulltext])
	completed: Boolean! @search
	user: User!
}

type User  @withSubscription @auth( query: { rule: "query($EMAIL: String!) { queryUser(filter: {email: { eq: $EMAIL } }){ email } }" }) {
	email: String! @search(by:[hash]) @id
	displayName: String!
	tasks: [Task] @hasInverse(field:user)
    createdAt: DateTime!
}

# Dgraph.Authorization {"Header":"X-Auth-Token","Namespace":"https://dgraph.io/jwt/claims","JWKURL":"https://www.googleapis.com/service_accounts/v1/jwk/securetoken@system.gserviceaccount.com","Audience":["MY_AUDIENCE"]}
  1. Add some todos…
  2. Try and delete them with this query:
mutation { deleteTask(filter: { id: "0xfffd8d6a978a685b" }) { task { title completed user { email } } numUids msg } }

And it does not work, get this error:

[GraphQL] couldn't execute query for mutation deleteTask because Dgraph execution failed because Some variables are defined but not used
Defined:[Task_3 Task_5 Task_Auth6 User_Auth4 x]
Used:[Task_3 Task_5 Task_Auth6 x]

Expected behavior and actual result.

Item would get deleted with no error.

However, this does work fine (by not returning any task):

mutation { deleteTask(filter: { id: "0xfffd8d6aa9866395" }) { numUids msg } }

Not sure if this is related to this post:

It is also worth noting that I am using subscriptions and urql, so it is not as important to keep the cache up-to-date with a return value, however, I would imagine it should still not produce this error.

J