[
https://issues.apache.org/jira/browse/KUDU-2217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16255995#comment-16255995
]
Todd Lipcon commented on KUDU-2217:
-----------------------------------
That's interesting. This implies that we have a config change op 1.3 which has
its "new_config.index" set to 2 instead of 3. It seems, though, that whenever a
pending op is added in AddPendingOperationUnlocked, we are forcing the
new_config().index() to match the op index. Maybe we can add a DCHECK into the
code that checks the above invariant when committing a change config and try
looping this test?
> Clarify on report about decreasing index of committed Raft config
> -----------------------------------------------------------------
>
> Key: KUDU-2217
> URL: https://issues.apache.org/jira/browse/KUDU-2217
> Project: Kudu
> Issue Type: Task
> Components: consensus, test
> Reporter: Alexey Serbin
> Assignee: Alexey Serbin
>
> Prior bf1fcb0df5f2fbb6d1557b6b932bc67045fff531 changelist, the
> RaftConsensusNonVoterITest.PromoteAndDemote scenario exhibited flakiness when
> running the binary built in DEBUG configuration. In addition to being flaky,
> the test output some interesting error messages, e.g. it was something like
> {noformat}
> I1030 22:33:14.041613 12284 raft_consensus.cc:2456] T
> 2abeb033beb040499f686713f41ba96c P 9e14a0231da149b2926039f26070025d [term 1
> FOLLOWER]: Committing config change with OpId 1.3: config changed from index
> 3 to 2, ...
> {noformat}
> Unfortunately, I could not find the log from that run, but I remember how
> [~mpercy] and I were looking at the message, wondering why committed index
> went down from 3 to 2.
> It would be nice to reproduce that and understand what is the reason behind.
> It might be a regression.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
