[
https://issues.apache.org/jira/browse/IGNITE-26411?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-26411:
--------------------------------------
Description:
Looks like some tests are not using the following StorageUpdateHandler methods
correctly:
* handleUpdate(...)
* handleUpdateAll(...)
This means that the following parameter set invariant is violated:
{code:java}
assert trackWriteIntent || commitTs != null
{code}
When writing data to storage, two main situations are possible.
# The transaction is complete - the transaction is committed (in this case,
commitTs != null)
# The transaction is not complete - changes are accumulated (in this case,
trackWriteIntent=true)
However, the following tests pass commitTs=null along with
trackWriteIntent=false
* StorageCleanupTest.testCleanupBeforeUpdateNoData
* StorageCleanupTest.testCleanupAndUpdateRowBatch
* StorageCleanupTest.testCleanupAndUpdateRow
* IndexGcTest.testRemoveTombstonesRowRowNull
* IndexGcTest.testRemoveStaleEntriesWithDifferentIndexes
* IndexGcTest.testRemoveTombstonesRowNullRow
* IndexGcTest.testRemoveTombstonesRowNullNull
* IndexGcTest.testRemoveStaleEntryWithSameIndex
This is inconvenient and can lead to errors in the future, since it requires
adding separate checks in production code (IGNITE-26067) that are not possible
in a production scenario.
was:
Looks like some tests are not using the following StorageUpdateHandler methods
correctly:
* handleUpdate(...)
* handleUpdateAll(...)
This means that the following parameter set invariant is violated:
{code:java}
assert trackWriteIntent || commitTs != null
{code}
When writing data to storage, two main situations are possible.
# The transaction is complete - the transaction is committed (in this case,
commitTs != null)
# The transaction is not complete - changes are accumulated (in this case,
trackWriteIntent=true)
However, the following tests pass commitTs=null along with
trackWriteIntent=false
* StorageCleanupTest.testCleanupBeforeUpdateNoData
* StorageCleanupTest.testCleanupAndUpdateRowBatch
* StorageCleanupTest.testCleanupAndUpdateRow
* IndexGcTest.testRemoveTombstonesRowRowNull
* IndexGcTest.testRemoveStaleEntriesWithDifferentIndexes
* IndexGcTest.testRemoveTombstonesRowNullRow
* IndexGcTest.testRemoveTombstonesRowNullNull
* IndexGcTest.testRemoveStaleEntryWithSameIndex
This is inconvenient and can lead to errors in the future, since it requires
adding separate checks in production code (eg IGNITE-26067) that are not
possible in a production scenario.
> Revise existing storage tests (StorageCleanupTest, IndexGcTest)
> ---------------------------------------------------------------
>
> Key: IGNITE-26411
> URL: https://issues.apache.org/jira/browse/IGNITE-26411
> Project: Ignite
> Issue Type: Improvement
> Components: transactions ai3
> Reporter: Pavel Pereslegin
> Priority: Major
> Labels: ignite-3
>
> Looks like some tests are not using the following StorageUpdateHandler
> methods correctly:
> * handleUpdate(...)
> * handleUpdateAll(...)
> This means that the following parameter set invariant is violated:
> {code:java}
> assert trackWriteIntent || commitTs != null
> {code}
> When writing data to storage, two main situations are possible.
> # The transaction is complete - the transaction is committed (in this case,
> commitTs != null)
> # The transaction is not complete - changes are accumulated (in this case,
> trackWriteIntent=true)
> However, the following tests pass commitTs=null along with
> trackWriteIntent=false
> * StorageCleanupTest.testCleanupBeforeUpdateNoData
> * StorageCleanupTest.testCleanupAndUpdateRowBatch
> * StorageCleanupTest.testCleanupAndUpdateRow
> * IndexGcTest.testRemoveTombstonesRowRowNull
> * IndexGcTest.testRemoveStaleEntriesWithDifferentIndexes
> * IndexGcTest.testRemoveTombstonesRowNullRow
> * IndexGcTest.testRemoveTombstonesRowNullNull
> * IndexGcTest.testRemoveStaleEntryWithSameIndex
> This is inconvenient and can lead to errors in the future, since it requires
> adding separate checks in production code (IGNITE-26067) that are not
> possible in a production scenario.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
