tkhurana commented on code in PR #2640:
URL: https://github.com/apache/phoenix/pull/2640#discussion_r4333403517
##########
phoenix-core/src/it/java/org/apache/phoenix/jdbc/HAGroupStoreManagerIT.java:
##########
@@ -743,6 +747,23 @@ public void
testE2EFailoverFromActiveNotInSyncWithAutomaticStateTransitions() th
waitForHAGroupState(cluster2HAManager, haGroupName,
HAGroupStoreRecord.HAGroupState.DEGRADED_STANDBY);
+ try {
+ cluster1HAManager.initiateFailoverOnActiveCluster(haGroupName);
+ fail("Failover from ACTIVE_NOT_IN_SYNC should be rejected");
+ } catch (InvalidClusterRoleTransitionException e) {
+ assertTrue(e.getMessage(),
e.getMessage().contains("store-and-forward"));
+ }
+ // Rejection lands well inside the anti-flap window, so the group cannot
have resynced yet.
Review Comment:
The assertion that cluster1 is still ACTIVE_NOT_IN_SYNC right after the
rejection depends on timing. It holds only if the check runs before the
anti-flap wait ends and the forwarder moves the group back to
ACTIVE_IN_SYNC. On a slow or loaded CI run, the group can already have
resynced by then, and the test fails even though the rejection behaved
correctly.
What we care about here is that the rejected failover changed nothing. So
it might be more robust to assert that neither cluster entered a failover
state, for example:
HAGroupStoreRecord.HAGroupState c1 =
cluster1HAManager.getHAGroupStoreRecord(haGroupName).get().getHAGroupState();
assertTrue("Rejected failover must not move the active: " + c1,
c1 == HAGroupStoreRecord.HAGroupState.ACTIVE_NOT_IN_SYNC
|| c1 == HAGroupStoreRecord.HAGroupState.ACTIVE_IN_SYNC);
HAGroupStoreRecord.HAGroupState c2 =
cluster2HAManager.getHAGroupStoreRecord(haGroupName).get().getHAGroupState();
assertTrue("Rejected failover must not move the standby: " + c2,
c2 == HAGroupStoreRecord.HAGroupState.DEGRADED_STANDBY
|| c2 == HAGroupStoreRecord.HAGroupState.STANDBY);
That still catches a failover that slipped through, which would show as
ACTIVE_IN_SYNC_TO_STANDBY / ACTIVE_NOT_IN_SYNC_TO_STANDBY on cluster1 or
STANDBY_TO_ACTIVE on cluster2, without depending on the
anti-flap timing.
--
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]
