[
https://issues.apache.org/jira/browse/CASSANDRA-15019?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16792936#comment-16792936
]
Jordan West commented on CASSANDRA-15019:
-----------------------------------------
This looks like the simplest patch to fix this but I wonder if we would be
better served in the future by fixing the functions that copy `ReadCommand`'s
to correctly copy the tracking flag. The patch would be a bit bigger for sure
(needing to modify each function and potentially the constructor) but it would
be more likely prevent this mistake in the future and would clarify the
disabling of the flag for transient replicas.
Happy to +1 it as is but wanted to toss that out there first.
> Repaired data tracking isn't working for range queries
> ------------------------------------------------------
>
> Key: CASSANDRA-15019
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15019
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Coordination, Consistency/Repair, Test/dtest
> Reporter: Sam Tunnicliffe
> Assignee: Sam Tunnicliffe
> Priority: Normal
> Fix For: 4.0
>
>
> CASSANDRA-14145 introduced optional tracking of the repaired dataset used to
> construct a read response. If enabled, each replica computes a digest for the
> repaired portion of the data, which the coordinator compares in order to
> detect divergence between replicas. This isn't working correctly for range
> reads, as the ReadCommand instance that the DataResolver is intialized with
> does not have the tracking flag set. This has been undetected up until now as
> the dtest which should verify it also has a bug in that when the relevant
> range query is issued the test expectations are being incorrectly set.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
