[BUG] Error codes / messages differ from Neo4j: uniqueness violation as SyntaxError / TransactionCommitFailed, static type checks (list positions, property access, operator types), subquery variable shadowing accepted, vector procedures on a missing index return rows, no statement position in messages (family)

[mm0nst3r]

Bug Description

When a statement violates a uniqueness constraint, Neo4j reports Neo.ClientError.Schema.ConstraintValidationFailed. NornicDB reports a different code on every path:

• Bolt auto-commit: Neo.ClientError.Statement.SyntaxError. The message is failed to create node: Constraint violation (UNIQUE on U.[k]): Node with k=1 already exists in batch.
• Bolt managed explicit transaction: Neo.ClientError.Transaction.TransactionCommitFailed. The server also closes the Bolt connection after the failed COMMIT (the driver logs Failed to read from defunct connection … OSError('No data')). Neo4j keeps the connection open and returns the failure.
• HTTP /tx/commit: Neo.ClientError.Statement.SyntaxError.

Consequence

Severity: wrong error class + dropped connection.

• Clients that handle a duplicate key by catching ConstraintValidationFailed (upsert-on-conflict, "already exists" messages, idempotent retries) don't recognise it. A duplicate reported as SyntaxError looks like a bug in the query.
• A client that treats TransactionCommitFailed as transient retries a write that will always fail.
• The closed connection forces the driver to discard it and reconnect after every violation inside a transaction.

Steps to Reproduce

Empty database:

CREATE CONSTRAINT u_k FOR (u:U) REQUIRE u.k IS UNIQUE
CREATE (:U {k: 5})

then each of these, via driver auto-commit, managed explicit transaction (session.execute_write) and HTTP /tx/commit:

CREATE (:U {k: 1}), (:U {k: 1})
CREATE (:U {k: 1})-[:R]->(:U {k: 1})
CREATE (:U {k: 2})-[:R]->(:T), (:U {k: 2})
CREATE (:T)-[:R]->(:T), (:U {k: 5})

Expected Behavior

Neo4j 5.26.30, on every path: Neo.ClientError.Schema.ConstraintValidationFailed, nothing written, and the connection stays usable.

Actual Behavior

NornicDB main 2d2d790: the codes listed above, and one closed Bolt connection per violating statement in a managed transaction. (On main, auto-commit and HTTP also keep part of the statement's nodes. That part is fixed by the #628 PR; the error codes and the closed connection are not.)

Environment

• NornicDB Version: main at 2d2d790
• Reference: neo4j:5.26.30-community (pinned in scripts/cypher-tck/run-differential.sh), neo4j Python driver 5.28.1 and HTTP /tx/commit
• OS: Linux container on Docker Desktop / WSL2
• Architecture: AMD64
• Build: -tags "noui,nolocalllm"

Related

• [BUG] HTTP /tx/commit returns every statement error with code SyntaxError (real code only inside the message); the explicit-transaction endpoint and Bolt are correct #575: HTTP /tx/commit reports every error as SyntaxError.
• [BUG] Server storage stack, auto-commit: a CREATE whose property expression fails stores the text ('1 / 0') with no error, or returns the error but keeps earlier writes #628: a failing CREATE writes nothing.

Checklist

• I have searched existing issues to ensure this is not a duplicate
• I have tested this with the latest version of NornicDB
• I have included all relevant information (environment, query, error messages)

🤖 Generated with Claude Code

[mm0nst3r]

Verified on main 2d2d790 against the pinned Neo4j 5.26.30, with CREATE CONSTRAINT u_k FOR (u:U) REQUIRE u.k IS UNIQUE and (:U {k: 5}) before each statement:

• error code: auto-commit Neo.ClientError.Statement.SyntaxError, explicit transaction Neo.ClientError.Transaction.TransactionCommitFailed. Neo4j: Neo.ClientError.Schema.ConstraintValidationFailed everywhere.
• partial writes in auto-commit: CREATE (:U {k: 1}), (:U {k: 1}), CREATE (:U {k: 1})-[:R]->(:U {k: 1}) and CREATE (:U {k: 2})-[:R]->(:T), (:U {k: 2}) leave 2 nodes instead of 1. That's the [BUG] Server storage stack, auto-commit: a CREATE whose property expression fails stores the text ('1 / 0') with no error, or returns the error but keeps earlier writes #628 non-atomicity. The explicit transaction leaves 1.
• connection loss: every violating statement in an explicit transaction drops the Bolt connection (the driver logs Failed to read from defunct connection).
• MATCH (u:U {k: 5}) SET u.k = 5 (same value) is accepted, as in Neo4j.

🤖 Generated with Claude Code

[mm0nst3r]

Added: other error codes and messages that differ from Neo4j over Bolt

Checked on main b017d0a against the pinned neo4j:5.26.30-community@sha256:3388e05e…. Python driver 5.28.1, Bolt auto-commit, database containing (:A {v: 1}).

statement	Neo4j 5.26.30: code / message	NornicDB: code / message
MATCH (n:A) RETURN n.v + {a: 1} AS y (the type is only known at run time)	Neo.ClientError.Statement.TypeError / Cannot add LongandMap``	Neo.ClientError.Statement.SyntaxError / …Type mismatch: expected Float, …
MATCH (n:A) RETURN toInteger(n) AS y (a type error Neo4j detects when compiling)	Neo.ClientError.Statement.SyntaxError / Type mismatch: expected Boolean, Float, Integer or String but was Node	Neo.ClientError.Statement.TypeError / …toInteger() cannot convert value…
RETURN 1 + {a: 1} AS y	SyntaxError	SyntaxError (same)
MATCH (n:A) RETURN n.v / 0 AS y	ArithmeticError	ArithmeticError (same)

The Bolt error message repeats the code. For example:

• RETURN 1 / 0 AS x: Neo4j's message is / by zero; NornicDB's is Neo.ClientError.Statement.ArithmeticError: / by zero;
• unknown function: Neo.ClientError.Statement.SyntaxError: unknown function: nosuch.

Over HTTP /tx/commit the message is the same as Neo4j's (/ by zero) on b017d0a. Mains 9646697 and 38eb1b9 had the prefix over HTTP too. The Bolt prefix is the same on 9646697, 38eb1b9 and b017d0a, so it is not a regression.

Consequence

Severity: wrong error classification.

• Clients and retry logic that branch on the error code treat a runtime type error as an invalid query (SyntaxError), and a compile-time type error as a runtime one.
• Applications that show or log error.message, or match on it, get the code repeated at the start of every Bolt message.

🤖 Generated with Claude Code

[mm0nst3r]

Duplicate code paths to converge with this fix (from #547). The fix site here overlaps these pairs, which implement the same behaviour separately. Fixing only one copy leaves the sibling to produce the same class of bug:

• Static vs runtime argument checks (match_semantic_validation.go:134 / semantic_validation.go:83 vs row_graph_function_validation.go:107): the compile-time-SyntaxError vs runtime-TypeError split in the "Added" section comes from these two checks.
• CREATE-target vs SET-target semantic validation (semantic_validation.go:93, 102).
• Constraint contracts: validation at creation vs at commit (storage/constraint_contracts.go:305 → :334-355 vs BadgerTransaction.validateConstraintContracts :1266, 1292): different error sources for the same violation (see also [BUG] A constraint violation wedges the server: a concurrent UNIQUE insert commits a duplicate, or any DOMAIN violation is acknowledged then rejected at flush; afterwards deletes, SET and DDL fail for every client until restart #700).

🤖 Generated with Claude Code

[mm0nst3r]

Clarification to the constraint-contract bullet above, checked in the code on main 8205fc5. 35abdf5 made the creation-time and commit-time contract evaluators one implementation over a constraintGraphView. The two views still report a missing node differently:

• txConstraintView.Node (commit) maps ErrNotFound to nil, nil, which yields the localized StorageSchemaMissingRelationshipEndpoint (constraint_contracts.go:1364-1373, :465);
• engineConstraintView.Node (contract creation) returns engine.GetNode's raw ErrNotFound (:384-385).

The "same violation, different error" part of the entry remains. The edge source (engine adjacency vs transaction overlay) now differs only through the view.

🤖 Generated with Claude Code

[mm0nst3r]

Added: more error classes that differ from Neo4j (found by the implementation session, re-checked here)

Checked on main 8205fc5 against the pinned neo4j:5.26.30-community@sha256:3388e05e…. Bolt auto-commit and HTTP /tx/commit give the same codes on both sides.

statement	Neo4j 5.26.30	NornicDB 8205fc5
RETURN $p AS x (no p passed)	Statement.ParameterMissing	Statement.SyntaxError
UNWIND [1, 0] AS d RETURN d ORDER BY 1 / d	Statement.ArithmeticError	no error: [{d: 1}, {d: 0}] (silent)
UNWIND [1, 0] AS d RETURN 1 / d AS x	Statement.ArithmeticError	Statement.SyntaxError
RETURN [x IN [1, 0] | 1 / x] AS l	Statement.ArithmeticError	Statement.SyntaxError
CALL db.index.fulltext.queryNodes('nosuch_idx', 'x') YIELD node RETURN node	Procedure.ProcedureCallFailed	Statement.SyntaxError
CALL nope.x()	Procedure.ProcedureNotFound	Procedure.ProcedureError

RETURN 1 / 0 AS x alone is already ArithmeticError (section above). The division fails with the wrong class once it's evaluated per row (UNWIND) or inside a list comprehension, and not at all inside ORDER BY.

Consequence

Severity: wrong error classification; one silent wrong result.

• Clients that branch on the error class treat a missing parameter or a runtime division by zero as an invalid query, and an unknown procedure as a procedure failure.
• ORDER BY over an expression that divides by zero returns rows, in an unspecified order, instead of failing.

🤖 Generated with Claude Code

[mm0nst3r]

Remaining: static type inference (not in the #657 PR)

These cases still differ after the #657 branch. All were verified against Neo4j 5.26.30 on the B6 head. The static checker there rejects only operands whose type it knows (literals, graph variables, WITH/UNWIND literal aliases, function results, parameters). Neo4j infers a set of possible types for every expression: a property value is never a map, node or relationship; n.v * 2 is Float, Integer or Duration; -n.v is Float or Integer. The cases below need that inference.

Statement	Neo4j 5.26.30	NornicDB (#657 branch)
MATCH (n:A) WITH [n.v] AS l RETURN l * 2	SyntaxError "… but was List, List, List, List, …" (every property list type)	SyntaxError "… but was List"
MATCH (n:A) WITH n.v + 1 AS x RETURN x - 'a'	SyntaxError "expected Float or Integer but was String"	SyntaxError "expected Float, Integer or Duration but was String"
MATCH (n:A) RETURN n.b['a'] (also WITH n.b AS b RETURN b['a'])	SyntaxError "Type mismatch: list index must be given as Integer, but was String"	no error, null
MATCH (n:A) RETURN n.l['a']	same SyntaxError	TypeError "list subscript requires an INTEGER index, got string"
MATCH (n:A) RETURN toUpper(n.s * 2)	SyntaxError "expected String but was Float, Integer or Duration"	TypeError "Cannot multiply String and Long"
MATCH (n:A) RETURN toUpper(-n.v)	SyntaxError "expected String but was Float or Integer"	no error, '-1'
MATCH (n:A) RETURN size(n.v * 2)	SyntaxError "expected String or List but was Float, Integer or Duration"	SyntaxError "… but was Integer" (the runtime value's type)

Remaining: list value names in runtime errors

Neo4j names a stored property array LongArray[1] / StringArray[a], and any computed list (a literal, n.l + [2], [n.v]) List{Long(1)} (type name List in operator errors: "Cannot subtract Long from List"). NornicDB names a list by its element types, so a computed list of one scalar type is LongArray[1]. The Go value type can't tell them apart yet: stored integer and float arrays come back as []int64 / []float64, but stored string arrays as []interface{}, the same as computed lists.

Statement	Neo4j 5.26.30	NornicDB
WITH [1] AS x RETURN toInteger(x)	"… got: List{Long(1)}"	"… got: LongArray[1]"
MATCH (n:A) RETURN n.l + 1 - 1	TypeError "Cannot subtract Long from List"	"Cannot subtract Long from LongArray"
MATCH (n:A) RETURN toInteger(n.l)	"… got: LongArray[1]"	same

🤖 Generated with Claude Code

[mm0nst3r]

PR: #705

🤖 Generated with Claude Code

[mm0nst3r]

The PR moved to #710 (same commits, branch on orneryd/NornicDB).

🤖 Generated with Claude Code