pk_indexes aren't generated for queries with duplicate named bind variables

[cvybhu]

When the driver asks to prepare a statement, Scylla responds with a message that contains metadata about this prepared statement. pk_indexes is a field in this metadata which lets the driver know which bind variables it should use to calculate the partition token.

For example:

CREATE TABLE tks.tab (p1 int, p2 int, c int, PRIMARY KEY ((p1, p2), c));
SELECT * FROM tks.tab WHERE p1 = ? AND p2 = ? AND c = ?;

When the driver prepares this SELECT statement, Scylla responds with the following pk_indexes:

pk_indexes: [
        PartitionKeyIndex {
            index: 0,
            sequence: 0,
        },
        PartitionKeyIndex {
            index: 1,
            sequence: 1,
        },
    ],

The meaning is: "To calculate partition key token, the driver should take the bound values with indexes 0 and 1, concatenate them and then generate the hash"
This allows the driver to correctly compute the token, and send the queries to the nodes that own those token ranges.

The problem is that for some statements that use the same named variable twice, Scylla doesn't produce any pk_indexes, even though it could.

In this example:

CREATE TABLE tks.tab (p int, c int, PRIMARY KEY (p, c));
SELECT p FROM tks.tab WHERE p = :x AND c = :x;

PreparedMetadata looks like this:

PreparedMetadata {
    flags: 1,
    col_count: 1,
    pk_indexes: [],
    col_specs: [
        ColumnSpec {
            table_spec: TableSpec {
                ks_name: "tks",
                table_name: "tab",
            },
            name: "x",
            typ: Int,
        },
    ],
}

The pk_indexes field is empty, even though the driver would be able to calculate the token value using the first bind variable.

Because of this the queries will be send to a random node instead of the one that owns this token range. This isn't the end of the world, as the random node will forward the query to the correct one, but it would be more efficient to send it to the right node immediately.

Here's the relevant part in the CQL binary protocol: https://github.com/apache/cassandra/blob/1959502d8b16212479eecb076c89945c3f0f180c/doc/native_protocol_v4.spec#L699

[cvybhu]

This is most likely a regression caused by scylladb/scylladb@19a6e69

On 2021.1.16 PreparedMetadata looks like this (pk_indexes are correct):

PreparedMetadata {
    flags: 1,
    col_count: 2,
    pk_indexes: [
        PartitionKeyIndex {
            index: 0,
            sequence: 0,
        },
    ],
    col_specs: [
        ColumnSpec {
            table_spec: TableSpec {
                ks_name: "tks",
                table_name: "tab",
            },
            name: "x",
            typ: Int,
        },
        ColumnSpec {
            table_spec: TableSpec {
                ks_name: "tks",
                table_name: "tab",
            },
            name: "x",
            typ: Int,
        },
    ],
}

[cvybhu]

Here's the code I used to print the metadata: https://gist.github.com/cvybhu/23e5964a8daef57f8a5bd70651e6793d

[denesb]

Doesn't apply cleanly to 5.2, @cvybhu please prepare a backport PR.

[cvybhu]

Doesn't apply cleanly to 5.2, @cvybhu please prepare a backport PR.

@denesb sorry, but I don't work at Scylla anymore.