Details
-
Bug
-
Status: Open
-
Normal
-
Resolution: Unresolved
-
None
-
Availability - Response Crash
-
Critical
-
Challenging
-
Fuzz Test
-
All
-
None
Description
This is caused by the same piece of GROUP BY code that has caused CASSANDRA-16307: counting. Since we have to look one row ahead in order to “finish” the group, we’ll check out the next row but will return null to transformations (including RT closer one). RT Closer will not see the row and, since the iterator is considered done, it’ll complain that that’s not right.
Similar result can be achieved without paging, but with LIMIT 1.
Minimal repro:
try (Cluster cluster = init(builder().withNodes(1).start())) { cluster.schemaChange("CREATE TABLE distributed_test_keyspace.table_5 " + "(pk0 bigint,pk1 bigint,ck0 bigint,ck1 bigint, PRIMARY KEY ((pk0,pk1), ck0, ck1)) " + "WITH CLUSTERING ORDER BY (ck0 ASC,ck1 ASC);"); long pk1 = 1; long pk2 = 1; cluster.coordinator(1).execute("DELETE FROM distributed_test_keyspace.table_5 USING TIMESTAMP 100000 WHERE pk0=? AND pk1=? AND ck0>?;", ConsistencyLevel.QUORUM, pk1, pk2, 2L); cluster.coordinator(1).execute("INSERT INTO distributed_test_keyspace.table_5 (pk0,pk1,ck0,ck1) VALUES (?,?,?,?) USING TIMESTAMP 100001;", ConsistencyLevel.QUORUM, pk1, pk2, 1L, 1L); cluster.coordinator(1).execute("INSERT INTO distributed_test_keyspace.table_5 (pk0,pk1,ck0,ck1) VALUES (?,?,?,?) USING TIMESTAMP 100001;", ConsistencyLevel.QUORUM, pk1, pk2, 3L, 1L); cluster.coordinator(1).executeWithPaging("SELECT pk0,pk1,ck0,ck1 FROM distributed_test_keyspace.table_5 WHERE pk0=? AND pk1=? GROUP BY pk0,pk1,ck0;", ConsistencyLevel.QUORUM, 1, pk1, pk2); }