[ 
https://issues.apache.org/jira/browse/IGNITE-24172?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kirill Tkalenko updated IGNITE-24172:
-------------------------------------
    Fix Version/s: 3.1

> Fix flaky 
> IndexMetaStorageRecoveryTest#testMissingDropTableWithUpdateLwmBeforeRestart
> -------------------------------------------------------------------------------------
>
>                 Key: IGNITE-24172
>                 URL: https://issues.apache.org/jira/browse/IGNITE-24172
>             Project: Ignite
>          Issue Type: Bug
>            Reporter: Kirill Tkalenko
>            Assignee: Kirill Tkalenko
>            Priority: Major
>              Labels: ignite-3
>             Fix For: 3.1
>
>          Time Spent: 20m
>  Remaining Estimate: 0h
>
> Flaky 
> *org.apache.ignite.internal.table.distributed.index.IndexMetaStorageRecoveryTest#testMissingDropTableWithUpdateLwmBeforeRestart*
>  was detected, we need to investigate why it failed, the fail was detected on 
> the 
> [TC|https://ci.ignite.apache.org/viewLog.html?buildId=8737030&buildTypeId=ApacheIgnite3xGradle_Test_RunAllTests&fromSakuraUI=true],
>  it is reproduced locally quite rarely.
> At the moment, after restarting the components, the index meta removes from 
> the local cache but remains in the metastorage. We need to find out why this 
> is happening.
> The problem is that we use a test implementation of 
> *org.apache.ignite.internal.metastorage.impl.StandaloneMetaStorageManager*, 
> which internally uses mocked components, in particular 
> *org.apache.ignite.internal.raft.client.TopologyAwareRaftGroupService*, which 
> for some reason reordered the execution of raft commands. When adding 
> logging, it turned out that after restarting the components to restore the 
> index meta, we send an update command and then a key delete command, but in 
> the metastorage state machine they were executed in the reverse order, so 
> there is no meta in the local volatile cache, but there is in the metastorage.
> We need to protect ourselves from such a situation by supplementing the 
> conditions for updating keys in the metastorage.
> {noformat}
> org.opentest4j.AssertionFailedError: expected: <null> but was: <IndexMeta 
> [catalogVersion=3, indexId=4, tableId=3, tableVersionOnIndexCreation=1, 
> indexName=TEST_TABLE_PK, currentStatus=READ_ONLY, 
> statusChanges=UnmodifiableMap {AVAILABLE=MetaIndexStatusChange 
> [catalogVersion=2, activationTs=113723603341803522], 
> READ_ONLY=MetaIndexStatusChange [catalogVersion=3, 
> activationTs=113723603343048704]}]>
>       at 
> app//org.junit.jupiter.api.AssertionFailureBuilder.build(AssertionFailureBuilder.java:151)
>       at 
> app//org.junit.jupiter.api.AssertionFailureBuilder.buildAndThrow(AssertionFailureBuilder.java:132)
>       at app//org.junit.jupiter.api.AssertNull.failNotNull(AssertNull.java:50)
>       at app//org.junit.jupiter.api.AssertNull.assertNull(AssertNull.java:35)
>       at app//org.junit.jupiter.api.AssertNull.assertNull(AssertNull.java:30)
>       at app//org.junit.jupiter.api.Assertions.assertNull(Assertions.java:279)
>       at 
> app//org.apache.ignite.internal.table.distributed.index.IndexMetaStorageRecoveryTest.testMissingDropTableWithUpdateLwmBeforeRestart(IndexMetaStorageRecoveryTest.java:458)
>       at java.base@17.0.6/java.lang.reflect.Method.invoke(Method.java:568)
>       at java.base@17.0.6/java.util.ArrayList.forEach(ArrayList.java:1511)
>       at java.base@17.0.6/java.util.ArrayList.forEach(ArrayList.java:1511)
> {noformat}



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

Reply via email to