"unknown type" issue after dropping Dgraph schema/data and then resetting the schema

Report a GraphQL Bug

I am having an issue and wondering if anyone here has any insight into it. I am loading a fairly large schema into dgraph (just running locally using the Dgraph docker image) and for some reason, a large number of the types in my schema do not get added to Dgraph. So when I try to then add data to that type (through the graphql api) I get an error like Unknown type "AddmyTypeInput" for inserting data under the myType graphql object.

  1. as part of the code flow, we first drop the schema and data in Dgraph (using the admin endpoint), and then upload a new schema before pushing data to it

(this is in JS), we await the http call to drop the schema before trying to push the new schema but it seems like this is causing the issue where some types arent found in Dgraph (even though they are in the schema).

I wonder if Dgraph responds to the http request with a 200 before actually finishing the deletion of the schema

Any help with this would be apprecitated!

I can supply any more info like the Dgraph logs when this happens if needed.

What edition and version of Dgraph are you using?



  • [ x] SlashGraphQL
  • Dgraph (community edition/Dgraph Cloud)

If you are using the community edition or enterprise edition of Dgraph, please list the version:

Dgraph Version
$ v22.0.1

Have you tried reproducing the issue with the latest release?


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

call graphql admin endpoint with dropAll and then reinsert a large schema and try to push data to that new schema

It sounds like you are experiencing an issue with your GraphQL schema after dropping the schema and data in Dgraph and then trying to upload a new schema.

One potential issue could be that the schema is not being properly deleted or reset before you are trying to upload the new schema. You mentioned that you are using the dropAll It’s possible that this execution is not completing before you are trying to upload the new schema, which could cause issues with the schema not being properly reset.

BTW, have you checked the GraphQL schema? if it is missing some part of it.

You could try adding some delay between the dropAll call and the schema upload to see if that helps resolve the issue. Sometimes the cluster take longer to do this operation. As you mentioned it is a huge schema.

It’s also worth checking the Dgraph logs to see if there are any error messages or other useful information that might help identify the cause of the issue.

Yea that was my assumption is that Dgraph, while it is returning a 200 response to the request, has actually not completed the dropAll function internally. I did not see anything specific in the logs but I can post them here, maybe I am missing something. I did check the schema and all the types are there, I also verified it is a correct schema for Dgraph by successfully setting it on a new Dgraph instance. I tried adding a delay for an additional 5 seconds but did not see any behavior change. Is there any trigger or event I can hook into on Dgraph for when it is actually done deleting the schema and is ready for a new one to be set?

Apologies for the delay. I believe there is no way to know if the drop was completed. But it’s something we could add to the GraphQL Admin API. Today we have the Task query that shows the Queued, Running, Failed, Success and Unknown status of some tasks like Export, Backup and probably another one (I’m not sure, too much information for one head). But I’m pretty sure it doesn’t have it for Drop operation.

query Task {
  task(input: {id: "0x1"}) { kind status  lastUpdated }

Please, fill a feature request in our issues at github.


Ok I created an issue on git. Would the id for the task query returned from the drop operation call we make (once that is implemented)