[
https://issues.apache.org/jira/browse/CASSANDRA-14919?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16711443#comment-16711443
]
Sam Tunnicliffe commented on CASSANDRA-14919:
---------------------------------------------
{quote}For instance,
[here|https://github.com/beobal/cassandra/commit/b8bb748dca93deeae7c50319ab0634f599fedea9#diff-f53ee75d79fb30b497f6d1584d51d7d3R2429],
[here|https://github.com/beobal/cassandra/commit/b8bb748dca93deeae7c50319ab0634f599fedea9#diff-861bc950c82973fb8f97f179e35be7f3R1586]
and
[here|https://github.com/beobal/cassandra/commit/b8bb748dca93deeae7c50319ab0634f599fedea9#diff-f53ee75d79fb30b497f6d1584d51d7d3R374]
at least we pretty much require that there be no column name in the payload?
If this is somehow present, something looks likely to have gone awry, since we
are discarding it and have nothing in place to suggest this is OK (unlike
[here|https://github.com/beobal/cassandra/commit/b8bb748dca93deeae7c50319ab0634f599fedea9#diff-861bc950c82973fb8f97f179e35be7f3R1093])?
{quote}
Actually, in these slice cases (as opposed to RTs), this is safe and equivalent
to the pre-14568/14749 behaviour. Previously, the column name element from a
query slice would be erroneously identified as a collection name, but this was
not problematic as we only ever used the {{LegacyBound.slice}} field, which was
correctly constructed as a result of the final element being popped from the
list of components in {{decodeBound}}. The same thing holds now, the difference
being that we no longer incorrectly assign the {{LegacyBound}} a collection
name.
{quote}I'm also honestly not certain what the correct behaviour here is.
Presumably for thrift schemas, it is impossible to receive a collection name.
However I'm very out-of-touch with the compatibility mechanisms for accessing
CQL via thrift. Can we legitimately receive a collection RT? I doubt it, but I
cannot be sure.
{quote}
It's technically possible to receive a collection name here as they can always
be hand rolled, but that's also fine. If a client were to send a deletion with
a range slice that emulates a collection tombstone, we'd process it as normal
and delete the collection. It's going down exactly the same path as non-thrift
requests, so an invalid slice bound (e.g. like a bound ending with a missing or
non-collection column name) would be rejected.
> Regression in paging queries in mixed version clusters
> -------------------------------------------------------
>
> Key: CASSANDRA-14919
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14919
> Project: Cassandra
> Issue Type: Bug
> Components: CQL
> Reporter: Sam Tunnicliffe
> Assignee: Sam Tunnicliffe
> Priority: Critical
> Fix For: 3.0.x, 3.11.x
>
>
> The changes to handling legacy bounds in
> CASSANDRA-14568/CASSANDRA-14749/CASSANDRA-14912 break paging queries where
> the coordinator is a legacy node and the replica is an upgraded node.
> The long-held assumption made by {{LegacyLayout::decodeBound}} that "There
> can be more components than the clustering size only in the case this is the
> bound of a collection range tombstone." is not true as serialized paged read
> commands may also include these type of bounds in their {{SliceQueryFilter}}.
> The additional checks the more recent tickets add cause such queries to error
> when processed by a 3.0 replica.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
