[
https://issues.apache.org/jira/browse/CASSANDRA-14919?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16711474#comment-16711474
]
Benedict commented on CASSANDRA-14919:
--------------------------------------
bq. Actually, in these slice cases (as opposed to RTs), this is safe
But it isn't safe for the other end to have actually sent this, I think? Since
we ignore the value, we aren't going to be semantically equivalent to whatever
was intended - either the other end has a bug, asking for something
nonsensical, or we have a bug in that we treat it erroneously?
With paging we know it is fine because there are comments indicating we expect
the column name, and that our treatment of ignoring it is correct, but in these
cases I'm not sure it is logically possible to respond correctly to a request
with this component?
I agree ignoring it would be equivalent to 3.0.0 behaviour, but it might help
our future selves to document and enforce these expectations.
This isn't something I would block commit on, if you disagree though.
bq. It's technically possible to receive a collection name here
I agree it's technically possible, I am just unsure if our API intended to
actually support this, and if it is misuse to use it (if we are to introduce
assertions). Looking at 2.2, though, we only refuse super columns because our
new schema cannot support them. So it's probably the case that this remains
equivalent in behaviour to 2.2, which is all that really matters.
+1, however you decide to proceed.
> 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: [email protected]
For additional commands, e-mail: [email protected]
