[jira] [Commented] (IGNITE-18432) SafeTimeCandidateManager#commitIndex() fails assertion if indices have different terms

["Roman Puchkovskiy (Jira)" <ji...@apache.org>]

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

Roman Puchkovskiy commented on IGNITE-18432:
--------------------------------------------

{{ItTableRaftSnapshotsTest#entriesKeepAddendedAfterSnapshotInstallation()}} in branch ignite-18079 demonstrates the problem. On my machine, it hangs quite often (~50% of runs). (It does not fail because when the assertion is thrown this 'breaks' an FSM, so such Ignite node cannot stop (it tries to stop, but the stop hangs forever).

> SafeTimeCandidateManager#commitIndex() fails assertion if indices have different terms
> --------------------------------------------------------------------------------------
>
>                 Key: IGNITE-18432
>                 URL: https://issues.apache.org/jira/browse/IGNITE-18432
>             Project: Ignite
>          Issue Type: Bug
>            Reporter: Roman Puchkovskiy
>            Priority: Major
>              Labels: ignite-3
>             Fix For: 3.0.0-beta2
>
>
> {{SafeTimeCandidateManager#commitIndex()}} accepts a range of indices and a term corresponding to the last of these indices. It then tries to look up the corresponding timestamps by (index, term) pair.
> It might happen that it gets an inteval of indices where some of them have one term, others have another term (in other words, the batch it gets might contain indices from different terms). Example:
>  # A command with index 29 and term 1 is applied
>  # Leader is changed and new configuration 'entry' is applied with index 30 and term 2
>  # {{commitIndex()}} is called for this batch with lastIndex=28, index=30 and term 2, so it tries to look up an index (29,1) and fails to do so, failing the assertion



--
This message was sent by Atlassian Jira
(v8.20.10#820010)