[
https://issues.apache.org/jira/browse/KUDU-2718?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hao Hao reassigned KUDU-2718:
-----------------------------
Assignee: Hao Hao
> master_failover-itest when HMS is enabled is flaky
> --------------------------------------------------
>
> Key: KUDU-2718
> URL: https://issues.apache.org/jira/browse/KUDU-2718
> Project: Kudu
> Issue Type: Bug
> Components: test
> Affects Versions: 1.9.0
> Reporter: Adar Dembo
> Assignee: Hao Hao
> Priority: Major
> Attachments: master_failover-itest.1.txt
>
>
> This was a failure in
> HmsConfigurations/MasterFailoverTest.TestDeleteTableSync/1, where GetParam()
> = 2, but it's likely possible in every multi-master test with HMS integration
> enabled.
> It looks like there was a leader master election at the time that the client
> tried to create the table being tested. The master managed to create the
> table in HMS, but then there was a failure replicating in Raft because
> another master was elected leader. So the client retried the request on a
> different master, but the HMS piece of CreateTable failed because the HMS
> already knew about the table.
> Thing is, there's code to roll back the HMS table creation if this happens,
> so I don't see why the retried CreateTable failed at the HMS with "table
> already exists". Perhaps this is a case where even though we succeeded in
> dropping the table from HMS, it doesn't reflect that immediately?
> I'm attaching the full log.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
