[jira] [Commented] (CASSANDRA-13237) Legacy deserializer can create unexpected boundary range tombstones

["Branimir Lambov (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/CASSANDRA-13237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15874391#comment-15874391 ] 

Branimir Lambov commented on CASSANDRA-13237:
---------------------------------------------

The deserializer fix and test look good, but there are some problems in {{DataResolver}}:
- Shouldn't we be looking at {{openDeletionTime}} [here|https://github.com/pcmanus/cassandra/commit/ba7d1763c108a4a7d84b91ab9eb9b36d04efb0f5#diff-8781f9483cca1cfc87145c767295cc79R341]?
- Regardless of the result of that test, you are still setting {{markerToRepair}} on the [next line|https://github.com/pcmanus/cassandra/commit/ba7d1763c108a4a7d84b91ab9eb9b36d04efb0f5#diff-8781f9483cca1cfc87145c767295cc79R344] -- I don't think this is the intended behaviour.
- Is it too hard to write a test for the above?


> Legacy deserializer can create unexpected boundary range tombstones
> -------------------------------------------------------------------
>
>                 Key: CASSANDRA-13237
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-13237
>             Project: Cassandra
>          Issue Type: Bug
>            Reporter: Sylvain Lebresne
>            Assignee: Sylvain Lebresne
>             Fix For: 3.0.x, 3.11.x
>
>
> Most of the code don't generate a range tombstone boundary with the same deletion time on both side as this is basically useless, and there is some assertion in {{DataResolver}} that actually expect this. However, the deserializer for legacy sstable doesn't always properly avoid their creation and we can thus generate them (and break the {{DataResolver}} assertion.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)