CALL subquery SET may leave the carried outer variable stale #4182

ArcadeDB version
Observed on Docker images:

• arcadedata/arcadedb:26.3.2
• arcadedata/arcadedb:26.4.1-SNAPSHOT
• arcadedata/arcadedb:26.4.2

Environment

• Host OS: Windows 10
• Architecture: x86_64
• Deployment: Docker
• ArcadeDB endpoint: HTTP /api/v1/command/arcade
• Request mode matches ArcadeDB Studio:
  • language: opencypher
  • serializer: studio
• Differential comparison target: Neo4j Docker neo4j:latest

Describe the bug
If a CALL subquery updates a node through a carried outer variable, ArcadeDB may keep the outer variable stale after the subquery returns.

In the minimized repro below, the node is clearly updated inside the subquery:

SET n.score = 2

Neo4j then exposes the updated value through the same outer variable n.
ArcadeDB keeps returning the old value through n, even though the update is already visible to a fresh re-match.

So this is not a general write-failure bug.
It looks more like the outer variable keeps an old snapshot across the CALL boundary.

To Reproduce

Setup:

CREATE (:Node {score: 1});

Query:

MATCH (n:Node)
CALL {
  WITH n
  SET n.score = 2
  RETURN 1 AS ok
}
RETURN n.score AS score;

Expected behavior
Observed Neo4j result:

2

ArcadeDB should return the same updated value.

Actual behavior
Observed ArcadeDB result on all tested versions:

1

So the write happens inside the subquery, but the carried outer variable still exposes the old property value.

Control cases

A plain in-query SET without the CALL subquery behaves correctly:

MATCH (n:Node)
SET n.score = 2
RETURN n.score AS score;

Observed result on Neo4j and all tested ArcadeDB versions:

2

If the updated node is returned explicitly from the subquery, ArcadeDB is also correct:

MATCH (n:Node)
CALL {
  WITH n
  SET n.score = 2
  RETURN n AS updated
}
RETURN updated.score AS score;

Observed result on Neo4j and all tested ArcadeDB versions:

2

If the node is re-matched after the subquery, ArcadeDB again sees the update:

MATCH (n:Node)
CALL {
  WITH n
  SET n.score = 2
  RETURN 1 AS ok
}
WITH count(*) AS _
MATCH (m:Node)
RETURN m.score AS score;

Observed result on Neo4j and all tested ArcadeDB versions:

2

So the update is not lost.
The bad behavior is specifically that the carried outer variable n remains stale after the subquery returns.

Stronger current differential variant

The same family surfaced in the current feature-only random differential in a noisier vector-property shape:

Setup:

CREATE (:TestNode {id: 1, vector: [1.0, 2.0, 3.0]});

Query:

MATCH (n:TestNode)
CALL {
  WITH n
  SET n.vector = [4.0, 5.0, 6.0]
} IN TRANSACTIONS OF 1000 ROWS
RETURN n;

Observed results:

• Neo4j:

{id: 1, vector: [4.0, 5.0, 6.0]}

• ArcadeDB 26.4.2:

{id: 1, vector: [1.0, 2.0, 3.0]}

Direct minimization shows that IN TRANSACTIONS is not required for reproduction.
The smaller root cause is already visible with an ordinary CALL subquery and a scalar property.