ivanzlenko commented on code in PR #6693:
URL: https://github.com/apache/ignite-3/pull/6693#discussion_r2402086286
##########
modules/index/src/integrationTest/java/org/apache/ignite/internal/index/ItBuildIndexTest.java:
##########
@@ -213,6 +223,137 @@ private static void changePrimaryReplica(IgniteImpl
currentPrimary) throws Inter
assertThat(sendBuildIndexCommandFuture, willSucceedFast());
}
+ @Test
+ @Disabled("https://issues.apache.org/jira/browse/IGNITE-21546";)
+ void writeIntentFromTxAbandonedBeforeShouldNotBeIndexed() throws Exception
{
+ createTable(1, 1);
+
+ disableWriteIntentSwitchExecution();
+
+ // Create and abandon a transaction.
+ int txCoordinatorOrdinal = 2;
+ Transaction tx =
CLUSTER.node(txCoordinatorOrdinal).transactions().begin();
+ insertDataInTransaction(tx, TABLE_NAME, List.of("I0", "I1"), new
Object[]{1, 1});
+
+ CLUSTER.restartNode(txCoordinatorOrdinal);
+
+ createIndex(INDEX_NAME);
+ assertTrue(
+ waitForCondition(() ->
isIndexAvailable(unwrapIgniteImpl(CLUSTER.aliveNode()), INDEX_NAME), 10_000),
+ "Index did not become available in time"
+ );
Review Comment:
Just for clarity: waitForCondition() will result in either true or false.
Exactly what happened and what condition was not met we will never know. And
some description in the assert will not help in that case. Especially if we
have a complex assertion.
On the other hand awaitility works directly with matchers and it will be
crystal clear what went wrong.
waitForCondition in itself is perfectly fine instrument if we want to just
wait until certain condition and not assert the result of this wait.
##########
modules/index/src/integrationTest/java/org/apache/ignite/internal/index/ItBuildIndexTest.java:
##########
@@ -213,6 +223,137 @@ private static void changePrimaryReplica(IgniteImpl
currentPrimary) throws Inter
assertThat(sendBuildIndexCommandFuture, willSucceedFast());
}
+ @Test
+ @Disabled("https://issues.apache.org/jira/browse/IGNITE-21546";)
+ void writeIntentFromTxAbandonedBeforeShouldNotBeIndexed() throws Exception
{
+ createTable(1, 1);
+
+ disableWriteIntentSwitchExecution();
+
+ // Create and abandon a transaction.
+ int txCoordinatorOrdinal = 2;
+ Transaction tx =
CLUSTER.node(txCoordinatorOrdinal).transactions().begin();
+ insertDataInTransaction(tx, TABLE_NAME, List.of("I0", "I1"), new
Object[]{1, 1});
+
+ CLUSTER.restartNode(txCoordinatorOrdinal);
+
+ createIndex(INDEX_NAME);
+ assertTrue(
+ waitForCondition(() ->
isIndexAvailable(unwrapIgniteImpl(CLUSTER.aliveNode()), INDEX_NAME), 10_000),
+ "Index did not become available in time"
+ );
Review Comment:
> I understand. But we also use waitForCondition() for the same end, and
it's used in more places, I guess. Consistency is a powerful property. If we
want to change the situation, we need to convert at least file by file, and in
this case I don't want to do the conversion as this PR is about something
different.
Yes, and we need to start somehow. If we have new and better instrument we
want to introduce it as soon as possible giving no shit to the existing code.
The existing stuff could be converted later case by case. If we will continue
to use inappropriate practices it will never end. Because someone will look at
your test and will decide that waitForCondition is the only option.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
