Repository navigation
HA: since #10040 a Cypher CREATE with a new label inside a client transaction on a follower is refused instead of forwarded #10067
Description
Found while fixing #10060.
Since #10047 (issue #10040), a write sent to a follower inside a transaction the client opened (Bolt BEGIN, Postgres BEGIN, an HTTP session) runs in that transaction on the follower instead of being forwarded to the leader. RaftReplicatedDatabase.runsInTheClientTransaction keeps forwarding statements the analyzer reports as DDL, but an openCypher CREATE (n:NewLabel ...) / MERGE whose label has no type yet is not DDL to the analyzer: it creates the type implicitly while executing. On a follower that is a schema change, so the statement is now refused with ServerIsNotTheLeaderException("Changes to the schema must be executed on the leader server").
Before #10047 the same statement was forwarded and succeeded. This is what turned Issue9870BoltFollowerLeaderRefusalIT.aWriteInAnExplicitTransactionOnAFollowerIsAnsweredNotALeaderNamingTheLeader red (#10060): the explicit transaction now hits the schema refusal rather than the forwarding refusal the test injected. #10060 only fixed the leader address that refusal names.
Effect on a correctly configured cluster: a routing (neo4j://) driver gets NotALeader and re-runs the transaction on the leader, so it recovers; a direct bolt:// / Postgres / HTTP-session client on a follower gets an error for a write that used to work, the first time it uses a new label inside an explicit transaction.
To decide: is this the intended trade of #10040 (document it: create types first, or outside the transaction), or should a statement that would create a type be detected and handled (refused up front with a clearer message, or forwarded)?
Reproduce: Issue10060SchemaRefusalNamesTheLeaderIT.aSchemaRefusalOnAFollowerOfAWellConfiguredClusterNamesTheLeadersHttpAddress (ha-raft) drives exactly this on a well-configured cluster.
Activity
fix(#10067): review round 1 - a transaction that wrote is re-based on…
fix(#10067): review round 2 - a type the leader made is not counted a…
fix(#10067): review round 3 - the statement a replica forwards for an…
fix(#10067): review round 4 - no SQL is built on an embedded database…
fix(#10067): review round 5 - CREATE TYPE IF NOT EXISTS holds against…
fix(#10067): review round 6 - an explicit bucket count or page size i…
1 remaining item
test(#10064,#10067): pin the concurrent type map the unlocked pre-che…
Merge pull request #10078 from ArcadeData/worktree-arcadedb-10064-100…
lvca commentedon Oct 15, 2026
Fixed in #10078, released in 26.10.2.
A Cypher
CREATEorMERGEwith a new label or relationship type, inside a transaction the client opened (BoltBEGIN, an HTTP session) on a follower, was refused: creating the type is a schema change a follower cannot make.The follower now asks the leader to create the missing type and carries on with the data write in the client's own transaction.
CREATE ... TYPE ... IF NOT EXISTSnow also holds against a concurrent creation.❤️ Thanks for helping make ArcadeDB better! ArcadeDB is free and open source, sustained by its community. If it's useful to you or your company, please consider becoming a sponsor to keep development going.
fix: ArcadeData#10064 ArcadeData#10066 ArcadeData#10067 ArcadeData#10068
fix: #10064 #10066 #10067 #10068 - one value contract for TIMESERIES …
fix(#10067): review round 1 - a transaction that wrote is re-based on…
fix(#10067): review round 2 - a type the leader made is not counted a…
fix(#10067): review round 3 - the statement a replica forwards for an…
fix(#10067): review round 4 - no SQL is built on an embedded database…
fix(#10067): review round 5 - CREATE TYPE IF NOT EXISTS holds against…
fix(#10067): review round 6 - an explicit bucket count or page size i…
fix(#10067): review round 7 - the wait for a type the leader created …
test(#10064,#10067): pin the concurrent type map the unlocked pre-che…