Bug: Kuzu gives wrong results with Python/Java API

Aurora-yzj commented 3 months ago

Kùzu version

v0.4.2

What operating system are you using?

Ubuntu 22.04 with Python or Java API

What happened?

Hi! I discovered that Kuzu could give the wrong result when using Python or Java APIs. Detailed reproduce process is as follows.

For example, use the following python script to execute queries:

import kuzu
db = kuzu.Database("./test")
driver = kuzu.Connection(db)
reader = open("testcase.log", "r")
lines = reader.readlines()
reader.close()
for l in lines:
    query = l.strip()
    response = driver.execute(query)
    results = list()
    while response.has_next():
        results.append(response.get_next())
    print(results)

Then execute these queries, and pay attention to the last query's output:

CREATE NODE TABLE L2 (k11 STRING, k12 BOOLEAN, k13 STRING, k14 BOOLEAN, k15 BOOLEAN, k16 INT64, id INT64, PRIMARY KEY (id));
CREATE NODE TABLE L5 (k30 STRING, k31 INT64, k32 BOOLEAN, k33 INT64, k34 STRING, k35 STRING, id INT64, PRIMARY KEY (id));
CREATE NODE TABLE L6 (k36 INT64, k37 STRING, k38 INT64, k39 STRING, k40 BOOLEAN, id INT64, PRIMARY KEY (id));
CREATE REL TABLE T2 (FROM L6 TO L5, k62 BOOLEAN, k63 STRING, k64 STRING, k65 STRING, k66 BOOLEAN, k67 STRING, k68 INT64, id INT64);
CREATE REL TABLE T3 (FROM L2 TO L2, k69 BOOLEAN, k70 BOOLEAN, k71 STRING, k72 BOOLEAN, k73 INT64, k74 BOOLEAN, id INT64);
CREATE REL TABLE T9 (FROM L5 TO L2, k106 BOOLEAN, k107 INT64, k108 INT64, k109 STRING, k110 INT64, k111 BOOLEAN, id INT64);
CREATE REL TABLE T15 (FROM L5 TO L2, k143 STRING, k144 INT64, k145 STRING, k146 BOOLEAN, k147 BOOLEAN, k148 BOOLEAN, k149 INT64, id INT64);
CREATE (n0 :L2{k16 : -7415315685436228776, k11 : "2hfL5k", id : 0, k13 : "sVfIE", k12 : true, k15 : false, k14 : true});
CREATE (n0 :L6{k39 : "I9kmub3t2", k38 : -2381650226906190026, k40 : false, id : 1, k37 : "CWLYEUoY", k36 : 3771199461796176348});
CREATE (n0 :L5{k31 : -8910981820870835834, k30 : "V0fW9Jc", k33 : 9173021826252425138, id : 3, k35 : "qi5zkDY6X", k34 : "q7HhsFu"});
CREATE (n0 :L6{k39 : "eggPzJ", k38 : 6890520045380675598, k40 : true, id : 4, k37 : "2PhGeP", k36 : -976477671824449601});
CREATE (n0 :L2{k16 : -8608559410963830019, k11 : "IAxdHyYY", id : 5, k13 : "fbzhpoqZ", k12 : false, k15 : true, k14 : false});
MATCH (n0 {id : 3}), (n1 {id : 0}) CREATE(n0)-[r :T9{k110 : -1463312342531043794, k111 : false, id : 6, k107 : -4069448546548281938, k106 : false, k109 : "xgUVr", k108 : -237657916924472743}]->(n1);
MATCH (n0 {id : 0}), (n1 {id : 5}) CREATE(n0)-[r :T3{k71 : "1Y7EFYy", k70 : false, k73 : -372225865317618184, k72 : false, k74 : false, id : 7, k69 : false}]->(n1);
MATCH (n0 {id : 3}), (n1 {id : 5}) CREATE(n0)-[r :T15{k143 : "usSpw", k145 : "SI7m4qn6e", k144 : 2868271556845867053, k147 : false, k146 : false, k149 : -7923591788717250191, k148 : false, id : 8}]->(n1);
MATCH (n0 {id : 3}), (n1 {id : 0}) CREATE(n0)-[r :T9{k110 : 8295068871179123787, k111 : true, id : 9, k107 : 6717172410994139932, k106 : true, k109 : "bz0fKU", k108 : -97521764572769839}]->(n1);
MATCH (n0 {id : 1}), (n1 {id : 3}) CREATE(n0)-[r :T2{k62 : false, k64 : "zpHmAZSxt", k63 : "aiHOVzHBi", k66 : true, k65 : "CeviZEpGN", id : 10, k68 : -4179936662251848709, k67 : "5T9QdWu0X"}]->(n1);
MATCH (n0 {id : 0}), (n1 {id : 0}) CREATE(n0)-[r :T3{k71 : "IFU4X", k70 : false, k73 : -5875412367767852651, k72 : true, k74 : false, id : 11, k69 : false}]->(n1);
MATCH (n0 {id : 5}), (n1 {id : 0}) CREATE(n0)-[r :T3{k71 : "E9rry6qw3", k70 : true, k73 : -5046328919877311600, k72 : true, k74 : false, id : 12, k69 : true}]->(n1);
MATCH (n0)-[r0]->(n1 :L5)-[r1]->(n2)-[r2]->(n3 :L2), (n2)<-[r3]-(n3{k11:'IAxdHyYY'})<-[r4]-(n1{k34:'q7HhsFu'}) WHERE true RETURN n1.id, n2.id, r1.id

Two results are given, and the second result is wrong, as there does not exist a relation from id=3 node to id=3 node: The bug can also be reproduced with Java API. Could be relevant to help locate the root cause: the label constraints L2 to n3 is crucial to trigger the bug. Removing it, the test case will lead to the correct result.

Thank you!

Are there known steps to reproduce?

No response

prrao87 commented 3 months ago

Hi @Aurora-yzj, thanks for reporting! Could you also share the log file that you used in the Python script above so that we can reproduce?

Aurora-yzj commented 3 months ago

Hi @Aurora-yzj, thanks for reporting! Could you also share the log file that you used in the Python script above so that we can reproduce?

Thanks for your reply! The content of the log file is the queries provided above. Thanks for your help! testcase.log

andyfengHKU commented 3 months ago

I think this has been fixed in #3765. @Aurora-yzj you can give a try over nightly build or wait for our coming v0.5.0 release.

Aurora-yzj commented 3 months ago

I think this has been fixed in #3765. @Aurora-yzj you can give a try over nightly build or wait for our coming v0.5.0 release.

Indeed the nightly build doesn't produce this wrong result. Thanks!

kuzudb / kuzu