[
https://issues.apache.org/jira/browse/CASSANDRA-9749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14697382#comment-14697382
]
Ariel Weisberg commented on CASSANDRA-9749:
-------------------------------------------
I am struggling here with where to draw the line for testing the code you
worked on. I created CASANDRA-10080 for the missing coverage. I don't think
code review and JIRA is the right venue for deciding whether you should go fill
in more test coverage or not.
There are instances of handleReplayError [like this
one|https://github.com/apache/cassandra/compare/cassandra-2.2...blambov:9749-2.2#diff-348a1347dacf897385fb0a97116a1b5eR183]
that throw instead of logging or returning a value. I feel like even when
trying to constrain scope those are things that need to be tested for the
change to be done.
So if you are super saturated with 3.0 work that has to be in (no opportunity
to constrain scope) then this is +1. If you could legitimately spend more time
on it and make sure the cases that throw that didn't used to are tested then do
that first.
> CommitLogReplayer continues startup after encountering errors
> -------------------------------------------------------------
>
> Key: CASSANDRA-9749
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9749
> Project: Cassandra
> Issue Type: Bug
> Reporter: Blake Eggleston
> Assignee: Branimir Lambov
> Fix For: 2.2.x
>
>
> There are a few places where the commit log recovery method either skips
> sections or just returns when it encounters errors.
> Specifically if it can't read the header here:
> https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/db/commitlog/CommitLogReplayer.java#L298
> Or if there are compressor problems here:
> https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/db/commitlog/CommitLogReplayer.java#L314
> and here:
> https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/db/commitlog/CommitLogReplayer.java#L366
> Whether these are user-fixable or not, I think we should require more direct
> user intervention (ie: fix what's wrong, or remove the bad file and restart)
> since we're basically losing data.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)