Query sometimes fails with "Could not compile query due to insanely frequent schema changes" about neo4j HOT 4 CLOSED

Thanks for reporting, we will look into it.

from neo4j.

There exists a support case in parallel to this issue.

Short description of what is happening:
The query engine optimiser uses indexes and constraints for executing the query. In your scenario, these are added and removed while the optimiser runs and therefore, the optimiser needs to try to run again. It does that 20 times and after that it gives up with the error message that you see.

Without having looked into the details of your setup, I would recommend that if you need queries to be stably planned, to not on the same instance add and remove indexes and/or constraints.

I am sorry for this very high-level answer, I would hope that your support engineer can give you more guidance.

The support case has been closed on our side. I will therefore close this issue. Please reach out to support if you need more help regarding this issue.

from neo4j.

Thanks for the reply @arnefischereit.

In our project, we call CREATE INDEX IF NOT EXISTS ... before we write a given node type to the graph.

We only see this in our CI integration tests and never in production. These integration tests run on a neo4j docker container that is freshly spun up every time we push code to our Github repo. Since the integration tests write very small amounts of data, we could be calling CREATE INDEX.. much more frequently than in production where we would be writing signifcantly more data and therefore taking more time in between CREATE INDEX calls.

Could this be causing the behavior you're referring to where the query engine adds constraints frequently?

from neo4j.

Hi @achantavy,

That sounds right yes. I see 418 indexes in indexes.cypher, it may very well explain why the planner can't finalise its plan successfully.
Waiting a little bit longer for the indexes to be ready before executing your first query against the DB should do the trick in this case.

from neo4j.