[
https://issues.apache.org/jira/browse/KUDU-1927?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15905799#comment-15905799
]
Adar Dembo commented on KUDU-1927:
----------------------------------
bq. Curious: Why not just initialized leader_status_ (maybe even both) to
non-OK until we check and make sure it's actually fine?
Ignoring for a minute that there's no canonical "non-OK" status (i.e. we'd have
to pick something arbitrarily, and whatever we choose may introduce side
effects), it shouldn't be necessary in the first place, because leader_status()
DCHECKs if catalog_status() is not OK.
So, if you forgot to check catalog_status() before checking leader_status() and
catalog_status() was actually not OK, the new test (there is a new test,
right?) will crash.
> Potential race handling ConnectToMaster RPCs during leader transition
> ---------------------------------------------------------------------
>
> Key: KUDU-1927
> URL: https://issues.apache.org/jira/browse/KUDU-1927
> Project: Kudu
> Issue Type: Bug
> Components: master, security
> Affects Versions: 1.3.0
> Reporter: Todd Lipcon
>
> MasterServiceImpl::ConnectToMaster currently has a TODO that there might be a
> case where a client issues the RPC exactly as a leader is becoming active.
> The worry is that it may return a response indicating LEADER status, but
> without the ability to issue a key.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
