Details
-
Bug
-
Status: Open
-
Normal
-
Resolution: Unresolved
-
None
-
Correctness - Transient Incorrect Response
-
Normal
-
Normal
-
User Report
-
All
-
None
Description
While running an easy-cass-stress workload I queried system_views.queries and got this (edited for sanity):
thread_id | queued_micros | running_micros | task -----------------+---------------+----------------+---- MutationStage-2 | 0 | 0 | Mutation(keyspace='easy_cass_stress', key='3030312e302e3937363535', modifications=[\n [easy_cass_stress.random_access] key=001.0.97655 partition_deletion=deletedAt=-9223372036854775808, localDeletion=2147483647 columns=[[] | [value]]\n Row[info=[ts=1713501354789139] ]: row_id=291 | [value=SXFNPWZDYFHTUSBWMUQCTTRAHQWXMGYOHASTGDFYLILWMOSFQWZGKUAIPUUGCLTADKFFXZRQGKIJJLXNOQKMAIOVSSVMVSFSFAVPABIIHGQSGRPACFWCKYMZMSNZZARSBFVDASTMCRHAVAYHKQDZWFCHRUPDWZJVTEVIWKPMKLAOZGBUDFJVOPSAHLAIWOGNXZHCBVK ts=1713501354789139]\n]) ReadStage-4 | 0 | 6216 | SELECT * FROM easy_cass_stress.random_access WHERE partition_id = '001.0.18474' AND row_id = 746 LIMIT 5000 ALLOW FILTERING
What's interesting is that I supply neither a LIMIT or ALLOW FILTERING when I prepared the query. I assume the limit is coming from the driver, and while it's technically correct from the standpoint of what it does, it's not what I prepared so it's a little weird to see it there.
The ALLOW FILTERING, on the other hand, was definitely not prepared.
session.prepare("SELECT * from random_access WHERE partition_id = ? and row_id = ?")