GROUP BY queries using paging and CL>ONE/LOCAL_ONE. This dtest reproduces the problem:
try (Cluster cluster = init(Cluster.create(2)))
cluster.schemaChange(withKeyspace("CREATE TABLE %s.t (pk int, ck int, PRIMARY KEY (pk, ck))"));
ICoordinator coordinator = cluster.coordinator(1);
coordinator.execute(withKeyspace("INSERT INTO %s.t (pk, ck) VALUES (0, 0)"), ConsistencyLevel.ALL);
coordinator.execute(withKeyspace("INSERT INTO %s.t (pk, ck) VALUES (1, 1)"), ConsistencyLevel.ALL);
cluster.get(1).executeInternal(withKeyspace("DELETE FROM %s.t WHERE pk=0 AND ck=0"));
cluster.get(2).executeInternal(withKeyspace("DELETE FROM %s.t WHERE pk=1 AND ck=1"));
String query = withKeyspace("SELECT * FROM %s.t GROUP BY pk");
Iterator<Object> rows = coordinator.executeWithPaging(query, ConsistencyLevel.ALL, 1);
Using a 2-node cluster and RF=2, the test inserts two partitions in both nodes. Then it locally deletes each row in a separate node, so each node sees a different partition alive, but reconciliation should produce no alive partitions. However, a GROUP BY query using a page size of 1 wrongly returns one of the rows.
This has been detected during
CASSANDRA-16180, and it is probably related to CASSANDRA-15459, which solved a similar problem for group-by queries with limit, instead of paging.