`CALL db.labels() YIELD label` may nullify carried variables

[Silence6666668]

ArcadeDB version
Observed on Docker images:

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

Not reproduced on older local images because the procedure is not available there:

• arcadedata/arcadedb:26.3.2

On those older lines, the same queries fail with:

Procedure not found: db.labels

The 26.4.x line is different: db.labels() is accepted and returns labels, but previously bound variables are replaced with null.

Environment

• Host OS: Windows
• 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
On ArcadeDB 26.4.1-SNAPSHOT and 26.4.2, CALL db.labels() YIELD label may nullify variables that were already bound earlier in the same query.

In the minimized repro below, the query starts with a simple carried scalar:

WITH 1 AS x
CALL db.labels() YIELD label
RETURN x, label;

Neo4j keeps x = 1 for every row.
ArcadeDB returns label rows, but x becomes null.

This is not just about graph-bound variables.
The same failure also affects carried node variables and path endpoints.

To Reproduce

Query:

WITH 1 AS x
CALL db.labels() YIELD label
RETURN x, label
ORDER BY label
LIMIT 5;

Expected behavior
Neo4j returns rows like:

1, Airport
1, Book
1, City
...

ArcadeDB should preserve the carried scalar x in the same way.

Actual behavior
Observed ArcadeDB 26.4.1-SNAPSHOT / 26.4.2 result:

null, Animal
null, ChainPerson
null, Checked
...

So the procedure call yields rows, but the previously bound variable is lost.

Control cases

The procedure itself works and returns labels:

CALL db.labels() YIELD label
RETURN label
ORDER BY label
LIMIT 5;

Observed result on both Neo4j and ArcadeDB 26.4.1-SNAPSHOT / 26.4.2:

<label rows>

So the problem is not that db.labels() fails to execute.

A plain graph match without the procedure also preserves bound values correctly:

CREATE (a:Person {name:'Alice'})-[:FRIEND]->(b:Person {name:'Bob'});

MATCH (n:Person)-[:FRIEND]->(m:Person)
RETURN n.name AS n_name, m.name AS m_name;

Observed result on both Neo4j and ArcadeDB:

Alice, Bob

So the earlier bound variables themselves are valid.

The failure starts when the carried variables cross the CALL db.labels() YIELD label boundary:

MATCH (n:Person)-[:FRIEND]->(m:Person)
CALL db.labels() YIELD label
RETURN n.name AS n_name, m.name AS m_name, label
ORDER BY label
LIMIT 5;

Observed results:

• Neo4j:

Alice, Bob, Airport
Alice, Bob, Book
Alice, Bob, City
...

• ArcadeDB 26.4.1-SNAPSHOT / 26.4.2:

null, null, Address/Animal/...

And the same thing still happens if the variables are materialized through WITH before the call:

MATCH (n:Person)-[:FRIEND]->(m:Person)
WITH n, m
CALL db.labels() YIELD label
RETURN n.name AS n_name, m.name AS m_name, label
ORDER BY label
LIMIT 5;

Observed ArcadeDB result:

null, null, <label>

So this is not a matter of a missing WITH.
The carried variables are already in scope, but db.labels() still wipes them out.

Why this matters
This is not a formatting difference and not just a missing-procedure issue on the current line.
ArcadeDB accepts the procedure call, returns rows, and silently corrupts the carried state by replacing bound values with null.
That can break later filtering, joins, writes, and aggregations in any query shape that combines a procedure call with previously bound variables.

[lvca]

Already fixed in current main. Added 1 regression test as a guard.