I've been busting my head over an integer value vs string property which I could not detect as it just did not give any error, not even a hint. And also the query was embedded in apoc.do.case, hence, no real visibility on what happens in there.
Explain and profile are not quite what I would call "debug" = being able to pause, as to check the variable value and the result of the function, step by step
Cutting and shortening the query into pieces and checking each piece individually is not really fun.
I think I have experienced the same situation, starring at a cypher query that is syntactically correct but does not behave at runtime as expected. Often I ended up with a trial and error approach by adding additional code to my cypher query that simulates a "breakpoint" we all now as developers from classical programming languages.
The purpose of these simulated breakpoints is to return intermediate results, enabling me as a developer to inspect what happens inside the query. I have implemented this "breakpoint like" behaviour with the following apoc function: "apoc.util.validatePredicate". Let's assume you have a variable with the name "test" somewhere in your cypher script and you want to return the value of "test" during runtime at a certain breakpoint. My approach is to add the following code: "with *, apoc.util.validatePredicate( true, "test="+apoc.convert.toString( test ), ) as breakpoint"
Essential the cypher query engine will throw an exception when it reaches the new code line and stopps the execution of the query, because the condition is set to "true" (see first parameter). In the second parameter you can define the content of the message that will be thrown, in this case the value of your variable "test".
I have developed also more sophisticated strategies for debugging, which I can share as well, but they need more explanation.