[
https://issues.apache.org/jira/browse/KUDU-1927?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15905764#comment-15905764
]
David Alves commented on KUDU-1927:
-----------------------------------
I think there is subtle bug in ScopedLeaderSharedLock in which whatever status
is returned by "leader_status()" should be checked after checking
"catalog_status()".
This is because statuses are, by default, initialized to OK and in its ctor,
ScopedLeaderSharedLock doesn't explicitly initialize leader_status_ or
catalog_status_.
Specifically, if catalog_->state_ != kRunning the lock would report a non-OK
status for catalog_status_ but an OK status for leader_status_.
> 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)
