Cassandra: a Query with a sort key condition and an ExclusiveStartKey answers InternalServerError #488

Summary

On the Cassandra backend, every Query that carries both a sort key condition and an ExclusiveStartKey answers InternalServerError. SQLite, PostgreSQL and the service answer the page.

Reproducer

Fresh table with pk S and sk S, items alice/a, alice/m, alice/z:

Query TableName=t
      KeyConditionExpression="pk = :p AND sk >= :v"
      ExpressionAttributeValues={":p": {"S": "alice"}, ":v": {"S": "a"}}
      ExclusiveStartKey={"pk": {"S": "alice"}, "sk": {"S": "m"}}

Expected (service, SQLite, PostgreSQL): Count 1, item z. Cassandra (main at 744ea29, cassandra:4.1 node): InternalServerError.

Server log:

ERROR extenddb_storage_cassandra::cassandra_util: query query failed: Server 127.0.0.1:9042 error: ErrorBody { message: "More than one restriction was found for the start bound on sk_s", ty: Invalid }

The reverse direction with an upper bound condition gives the end-bound form of the same error, and the index sub-query that reads rows sharing the cursor's sort value gives Column "sk_s" cannot be restricted by both an equality and an inequality relation.

Mechanism

The Cassandra Query path appends the start key as a second comparison on the clustering column the sort key condition already bounds, for example pk = ? AND sk_s >= ? AND sk_s > ?. Cassandra takes one restriction per side of a clustering column and refuses the statement; the server maps the storage error to InternalServerError. Requests whose start key bound lands on the other side of the condition's bound (reverse sk >= m with start key z, rendered sk_s >= ? AND sk_s < ?) pass, which is why ordinary forward pagination over pk = :p alone never showed it.

Fix

The start key must be folded into the condition's bound on the near side of the scan direction: one lower and one upper bound per statement, the near-side bound replaced by a strict bound at the start key when the start key is at or past the condition's bound, comparisons in the clustering column's order (text and blob by bytes, decimal numerically). The index two-query path must run the same-sort-value sub-query only when the start key lies inside the range.

Fixed in #483.