[
https://issues.apache.org/jira/browse/IGNITE-19255?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksandr Polovtcev reassigned IGNITE-19255:
--------------------------------------------
Assignee: Mirza Aliev
> Fix broken unit tests in distribution-zones module
> --------------------------------------------------
>
> Key: IGNITE-19255
> URL: https://issues.apache.org/jira/browse/IGNITE-19255
> Project: Ignite
> Issue Type: Bug
> Reporter: Aleksandr Polovtcev
> Assignee: Mirza Aliev
> Priority: Blocker
> Labels: ignite-3
>
> In IGNITE-19105 I've changed some internal shenanigans of the
> MetaStorageManager (without affecting its API in any way). After that, nearly
> all unit tests in the {{distribution-zones}} module started to fail. Turns
> out it happened because of extensive mock usages that emulate behavior of the
> Meta Storage. So I decided to replace it with the
> {{StandaloneMetaStorageManager}} implementation and all hell broke loose:
> many tests emulate Meta Storage incorrectly, a lot of races appeared, because
> many methods became truly asynchronous.
> This situation is very frustrating: a different component internals were
> changed with no API changes and a completely unrelated module is not longer
> able to pass its tests. Though I fixed most of the failures, some tests are
> still failing and I'm going to try to describe, what's wrong with them:
> *{{DistributionZoneManagerScaleUpTest#testDataNodesPropagationAfterScaleUpTriggeredOnNewCluster}}*
> - this test tests a scenario when we start a node after logical topology was
> updated. I don't know how realistic is this scenario, but the problem is that
> "data nodes" don't get populated with the logical topology nodes on
> {{distributionZoneManager}} start, because {{scheduleTimers}} method, that
> get's invoked from the Meta Storage Watch, doesn't go inside the {{if
> (!addedNodes.isEmpty() && autoAdjustScaleUp != INFINITE_TIMER_VALUE)}} branch.
> *{{DistributionZoneManagerScaleUpTest#testDataNodesPropagationForDefaultZoneAfterScaleUpTriggered}}*
> - same issue as above.
> *{{DistributionZoneManagerScaleUpTest#testDataNodesPropagationForDefaultZoneAfterScaleDownTriggered}}*
> - same issue as above.
> *{{DistributionZoneManagerScaleUpTest#testUpdateZoneScaleUpTriggersDataNodePropagation}}*
> - this test fails with the following assertion error: _Expected revision
> that is greater or equal to already seen meta storage events._. This is
> because TestConfigurationStorage does not use the same revision as the Meta
> Storage, therefore their revisions can't be compared directly. This should
> either be converted to an integration test or it should use
> `DistributedConfigurationStrorage` instead.
> *{{DistributionZoneManagerScaleUpTest#testUpdateZoneScaleDownTriggersDataNodePropagation}}*
> - same issue as above.
> *{{DistributionZoneManagerScaleUpTest#testScaleUpDidNotChangeDataNodesWhenTriggerKeyWasConcurrentlyChanged}}*
> - fails, because I had to comment the part which emulates a concurrent Meta
> Storage update. Nothing is wrong with this test, we simply need to invent a
> different way to emulate concurrent Meta Storage updates.
> *{{DistributionZoneManagerScaleUpTest#testScaleDownDidNotChangeDataNodesWhenTriggerKeyWasConcurrentlyChanged}}*
> - same issue as above.
> *{{DistributionZoneManagerWatchListenerTest#testDataNodesOfDefaultZoneUpdatedOnWatchListenerEvent}}*
> - this test is flaky, probably due to some races between Watch and
> Configuration Listener execution (sometimes a retry on {{invoke}} happens and
> {{Mockito#verify}} fails).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
