Yes it is, as the results are streamed, the headers are already sent out immediately before query execution happens.
Also as you can send many queries, the error contains more information on which (the last) query it happened. There is an error field in the response. Not sure how much effort it would be to rewrite the impl to wait for the first query to start and on failure during parsing/semantic check send an appropriate error code (the query results are also streamed directly so if an error happens during fetching query results the same as above applies). But then the behavior would be inconsistent depending on your offending query is the first or second which would be even more confusing. Michael Am 16.06.2014 um 23:07 schrieb Hadi Hariri <hadihar...@gmail.com>: > Hi, > > When using the transactional endpoint, when an error occurs, such as for > instance a unique constraint violation, the status code returned is still > 200. Is this by design? Is the preferred method to always have to examine > errors property in body to make sure it's empty to guarantee success? > > Thanks. > > > -- > You received this message because you are subscribed to the Google Groups > "Neo4j" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to neo4j+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "Neo4j" group. To unsubscribe from this group and stop receiving emails from it, send an email to neo4j+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
