Equality on a DOUBLE property with an integer literal returns empty when a property index on that property is used (scan path returns the row) #6171

Reporter: ting668

Environment

• OS: Linux (WSL2 host); NebulaGraph services inside Docker containers
• Docker images: vesoft/nebula-graphd:v3.8.0, vesoft/nebula-metad:v3.8.0, vesoft/nebula-storaged:v3.8.0 (Docker Compose)
• NebulaGraph Version: 3.8.0 (Git 7458486)

Description

While testing NebulaGraph using a method based on attribute-constraint analysis, I found that an equality predicate on a DOUBLE property compared with an integer literal returns a different result depending on whether the query is answered through a property index on that property or through a scan.

Two spaces with the same logical schema hold the vertex "n1" with f = 1.0 (one of them additionally holds "n2" with f = 2.0, which does not satisfy the predicate). The query WHERE v.metric.f == 1 returns "n1" in the space whose tag index is on name, and returns empty in the space whose tag index is on the compared property f.

How to Reproduce and Expected Behavior

Note: The queries below are a minimized, simplified example reproducing the bug.

Buggy query (with the minimal setup below):

-- Space 1: tag index on name (not on the compared property f).
CREATE SPACE repro_name_idx(partition_num=1,replica_factor=1,vid_type=FIXED_STRING(32));
USE repro_name_idx;
CREATE TAG metric(name string,i int,f double);
CREATE TAG INDEX metric_idx ON metric(name(16));
-- Wait for the space, schema, and index metadata to propagate via heartbeats before inserting.
INSERT VERTEX metric(name,i,f) VALUES "n1":("n1",1,1.0);

-- Space 2: identical schema, but the tag index is on the compared property f.
CREATE SPACE repro_f_idx(partition_num=1,replica_factor=1,vid_type=FIXED_STRING(32));
USE repro_f_idx;
CREATE TAG metric(name string,i int,f double);
CREATE TAG INDEX metric_idx ON metric(f);
-- Wait for the space, schema, and index metadata to propagate via heartbeats before inserting.
INSERT VERTEX metric(name,i,f) VALUES "n1":("n1",1,1.0),"n2":("n2",2,2.0);

-- The same query in both spaces:
USE repro_name_idx;
MATCH (v:metric) WHERE v.metric.f == 1
RETURN id(v) AS id ORDER BY id;

USE repro_f_idx;
MATCH (v:metric) WHERE v.metric.f == 1
RETURN id(v) AS id ORDER BY id;

Expected behavior: n1.f is 1.0, so the predicate v.metric.f == 1 holds for n1 in both spaces (adding n2, which does not satisfy it, must not remove n1 from the result):

id="n1"    (in both spaces)

Actual behavior: the space with the index on name returns the row; the space with the index on the compared property f returns empty:

repro_name_idx: id="n1"
repro_f_idx:    (empty result)

Control: in the space with the name index, replacing the numeric predicate with an explicit VID list still returns the row, confirming the data is present:

USE repro_name_idx;
MATCH (v:metric) WHERE id(v) IN ["n1"]
RETURN id(v) AS id ORDER BY id;

id="n1"

This suggests that when the equality predicate on the DOUBLE property f is answered through the property index on f, the comparison against the integer literal 1 drops the matching row, instead of behaving like the scan-and-filter evaluation which returns it.